A config file is just a text file full of console commands that Counter-Strike 2 runs for you, and using one is the difference between re-typing your settings constantly and having them apply automatically every time you launch. This guide explains how configs work in CS2, how to build an autoexec that loads your preferences, which key binds are genuinely useful, and how to make a practice config you can run with one command.
The config behavior described here was checked in October 2026 against Counter-Strike 2's file structure and console, plus community references including r/GlobalOffensive. File locations can shift with updates, so if your config does not load, confirm the current cfg folder path in your Steam installation before troubleshooting further.
How config files work
CS2 reads .cfg files — plain text files, one command per line — from the game's cfg folder inside your Steam installation. You can run any config at any time from the console with the exec command followed by the file name. The most common use is an autoexec: a file named so the game runs it at startup, or that you exec yourself, which applies all your personal settings in one go. This matters because some settings do not reliably persist through every update or install, and a written config is the authoritative record you can reapply instantly.
To build one, create a text file in the cfg folder, put one command per line, and save it. Then exec it from the console to apply everything. Keeping a single source of truth for your settings means you can reinstall the game, move to a new PC, or recover from an update that reset your preferences in seconds.
A couple of practical points save a lot of frustration. First, make sure the file genuinely ends in .cfg and not a hidden .txt extension, which is a common mistake if your operating system hides known extensions — a file that looks like autoexec.cfg but is actually autoexec.cfg.txt will not execute. Second, put commands that must run early, like those that enable other commands, near the top of the file, since the file runs top to bottom. And third, because the cfg folder's exact location inside the Steam installation can shift between updates, if your config suddenly stops loading the first thing to check is that you are editing the file in the folder the current version actually reads, rather than an old path from a previous install.

What goes in an autoexec
A good autoexec collects the settings you care about so none of them drift. Typical contents include your crosshair commands (see our crosshair guide), your viewmodel values, your sensitivity, and any gameplay preferences the menu does not expose cleanly. Put each command on its own line exactly as you would type it in the console. A short, well-commented autoexec is easier to maintain than a sprawling one copied from somewhere else — only include commands you understand and actually want, so you can always explain why a line is there.
If you adjust a setting in-game and like it, add or update the corresponding line in your autoexec so the change survives. Treating the file as your canonical settings record, rather than relying on the menu to remember everything, is the habit that keeps your setup stable over months of updates.
A habit worth adopting is commenting your config. Most config formats let you mark a line as a comment so the game ignores it, and using that to label sections — crosshair, viewmodel, binds, audio — and to note why an unusual line is there turns a wall of commands into something you can actually read and maintain months later. When you return to tweak one thing, comments let you find it instantly instead of parsing every line. They also make it far safer to share your config or ask for help, because anyone reading it can see your intent. A tidy, commented autoexec is the difference between a config you trust and one you are afraid to touch in case you break something you no longer understand.
Useful key binds
Binds map a command to a key, and a few are worth setting for everyone:
- Jump-throw bind — historically a single key that jumps and throws a grenade simultaneously for consistent lineups; CS2 added an official jump-throw bind option, so use the built-in one where available rather than a risky custom script.
- Dedicated utility keys — binding each grenade type (smoke, flash, molotov, HE) to its own key so you never fumble through the grenade carousel under pressure.
- Clear decals / drop bomb — small quality-of-life binds that save time.
- Buy binds — keys that instantly buy a specific loadout, so your buy phase is one keypress instead of navigating the menu.
Keep binds simple and legal. CS2 has clamped down on certain scripting behaviors over the years, so prefer the official in-game bind options — especially for jump-throw — over custom scripts that could break or be disallowed after an update.
Dedicated grenade keys deserve a closer look because they fix one of the most common pressure mistakes: fumbling through the grenade carousel and throwing the wrong nade at the wrong moment. Binding smoke, flash, molotov or incendiary, and HE each to their own key means that when you decide to smoke a choke, you hit one key and the smoke is in your hand instantly, with no scrolling and no risk of a flash coming out instead. This is one of the highest-value binds in the game for the effort involved, and it is a standard, allowed use of the bind command. Buy binds work on the same principle for the freeze-time buy phase: a single key that purchases a predefined loadout saves you from menu-clicking while your teammates are already calling the round, so you spend the buy phase communicating instead of shopping.

A practice config
The most useful config after your autoexec is a practice config that loads an entire training setup at once. Instead of typing sv_cheats, infinite ammo, grenade trajectory, and the rest every time, put them all in a file and exec it when you start a practice server. The full list of commands that belong in such a file is in our practice commands guide; collecting them into one config turns a five-minute setup into a single line. Many players bind that exec to a key so their whole practice environment is one press away.
Keep your practice config separate from your autoexec, because the practice commands require cheats and should never load in normal play. Having two clearly named files — one for everyday settings, one for training — keeps them from interfering with each other.
You can take the same idea further with purpose-built configs for different situations. Some players keep a small config that sets up a particular drill, another that loads a specific set of binds for a map they are learning, and so on, each run with a single exec when they want it. The key discipline is naming them clearly and keeping each one focused, so you always know what a given file does before you run it. A messy pile of half-remembered configs is worse than none, because executing the wrong one mid-session can quietly change settings you did not mean to touch. Treat your configs like a small, tidy toolkit: a few well-named files, each doing one obvious job, that together let you reshape your game with a single line whenever you need to.
Keeping it maintainable
The final piece of advice is to keep your configs clean and backed up. A config is a plain text file, so copying it somewhere safe means you can never truly lose your setup. Avoid pasting in enormous configs from unknown sources, both because they may contain commands you do not want and because a bloated config is hard to debug when something behaves oddly. A lean autoexec and a lean practice config, each containing only commands you chose deliberately, are easier to maintain and easier to trust.
It is also wise to back your configs up somewhere outside the game folder — a cloud drive, a notes file, anywhere you control. Because a config is just plain text, a copy pasted into a document is enough to survive a reinstall, a new PC, or an update that wipes the cfg folder. Players who have spent an afternoon rebuilding a setup from memory after losing it rarely make that mistake twice. Spend two minutes saving a copy now and your entire personalized setup becomes something you can restore anywhere in seconds, which is the whole reason to use configs rather than the menu in the first place.
Counter-Strike 2 accounts and services
A dialed-in config makes the game feel like yours, but it will not change the account you play on. If you need a Prime-ready profile or a rating that reflects your real level so your tuned setup gets a fair test, our Counter-Strike 2 accounts and services page covers accounts and boosting as a service. Everything in this guide uses Valve's own config system, and the storefront services never involve cheats or anything that risks a ban.
Frequently Asked Questions
What is an autoexec in CS2?
A config file that applies your personal settings automatically. It is a plain text file of console commands in the cfg folder, run at startup or via the exec command, that acts as the authoritative record of your preferences.
How do I run a config file?
Place the .cfg file in your CS2 cfg folder and type exec followed by the file name in the console. Every command in the file runs in order, applying your whole setup at once.
Are config binds and scripts allowed?
Standard binds are fine. CS2 has restricted some scripting over time, so prefer official in-game options — such as the built-in jump-throw bind — over custom scripts that could break or be disallowed after an update.
Why does my config keep resetting?
Some settings do not persist cleanly through every update. Keeping them in an autoexec and re-running it fixes this, which is exactly why a written config is more reliable than the menu alone.
Should my practice commands go in my autoexec?
No. Keep a separate practice config, because practice commands require sv_cheats and should never load in normal matches. Two clearly named files prevent them from interfering with each other.
Can I copy someone else's whole config?
You can, but it is better to build your own from commands you understand. A huge copied config may include settings you do not want and is hard to debug when something behaves unexpectedly.