config.toml
Every flag you have typed so far has a home. One file holds your defaults, and a second one can hold a project's.
sandbox_mode = "workspace-write"
approval_policy = "on-request"That is the pair from lesson 5, written down once instead of passed every time. The CLI and the IDE extension read the same layers, so setting it here sets it for both.
Where the layers are
User settings live in ~/.codex/config.toml. A project can carry its own in .codex/config.toml, which is the one you commit.
| Highest first | Layer |
|---|---|
| 1 | CLI flags and --config overrides |
| 2 | Project files, from the root down. Closest wins |
| 3 | Profile files, chosen with --profile |
| 4 | Your user config |
| 5 | Cloud-managed defaults for your workspace |
| 6 | System config, /etc/codex/config.toml |
| 7 | Built-in defaults |
Worth reading once, because it explains the two confusing cases: a flag that seems to be ignored is usually being overridden from above, and a setting that works for you and not a colleague is usually in your user file rather than the project's.
Profiles
A profile is a named set of settings in its own file, chosen per run.
codex --profile reviewUseful when you have two or three ways of working: a tight read-only profile for looking at unfamiliar code, and a wider one for your own repository. That is a different thing from the permission profiles in lesson 4, which are about what the sandbox allows, and the two are often set together.
- Write your preferred sandbox and approval pair into your user config.
- Add a
.codex/config.tomlto one repository and see it take precedence.
Slow is fine. Stopping is the only problem.