--- title: "Making an autoexec.cfg That Actually Loads" excerpt: "Where autoexec.cfg goes, why config.cfg keeps overwriting your settings, how to make an autoexec that wins, and the file-extension and quoting traps that stop it loading at all." category: "client" tags: "autoexec, config" image: "" read_time: "8 min read" ---
An autoexec.cfg is how you keep your rates, crosshair, binds and net settings in one file the game runs at startup — instead of retyping them or losing them when the game rewrites config.cfg. The trouble is that a naive autoexec often appears to do nothing: the settings load, then config.cfg loads on top and clobbers them, or the file has a hidden .txt extension and never runs. This is how to make one that actually sticks.
The file goes directly in your game's cstrike/ directory, next to config.cfg:
Steam/steamapps/common/Half-Life/cstrike/autoexec.cfg
Not in a subfolder, not in the Half-Life root — in cstrike/. The engine looks for it there at startup and executes it as console commands.
Each line is exactly what you would type in the console. Quote multi-word values:
// autoexec.cfg rate 25000 cl_updaterate 101 cl_cmdrate 101 cl_interp 0.01 fps_max 100 hud_fastswitch 1 bind "mouse4" "+voicerecord" crosshair 1 // a marker so you can prove it ran: developer 0 echo "autoexec.cfg loaded"
The echo line is a deliberate trick: if you see autoexec.cfg loaded in the console at startup, the file ran. If you never see it, the file is not being found — skip to the extension trap below.
Here is the core conflict: the game writes your current settings to config.cfg when you quit, and executes it at startup. If config.cfg loads after your autoexec, it overwrites anything you set. Two reliable fixes:
config.cfg and you do not need autoexec for them at all.config.cfg to read-only in file properties. The game can no longer overwrite it on quit, so it stops fighting your autoexec. The trade-off: changes you make in the menu no longer save, so do this only once your setup is final.For rates and binds — the things the menu does not fully cover — autoexec plus a read-only config is the combination that holds.
To remove all doubt about load order, execute the autoexec explicitly and last via a launch option. Right-click CS in Steam → Properties → Set Launch Options:
+exec autoexec.cfg
This runs the file at startup regardless of the internal order, and because it is processed as a startup command it lands after the normal config load on most builds. Combined with the read-only trick, your settings win.
The single most common reason an autoexec "does not load" is that it is not actually named autoexec.cfg. Windows hides known extensions by default, so a file you saved as autoexec.cfg in Notepad is really autoexec.cfg.txt — the engine never sees it. Turn on "File name extensions" in Explorer's View menu and confirm the name is exactly autoexec.cfg with no trailing .txt. Save it as plain ANSI/UTF-8 text without a byte-order mark; a stray BOM or curly "smart quotes" from a word processor break the first line. This is the same trap that silently breaks motd.txt on the server side.
echo message at startup — the file is misnamed (autoexec.cfg.txt) or in the wrong folder. Fix the extension and location.config.cfg overwrote them. Make config.cfg read-only or add +exec autoexec.cfg to launch options.config.cfg read-only. That is expected; toggle it writable to change menu settings, then set it back.Launch the game, open the console, and look for your echo "autoexec.cfg loaded" line at the top. Then read a value back by typing its name with no argument:
cl_updaterate rate
They should show what your autoexec set, not the defaults. Quit and relaunch to confirm they survive a restart — if a value reverts, config.cfg is still overwriting it and you need the read-only or +exec fix. Once it holds, build your keybinds on top with binds and aliases.