### What feature would you like to see? Currently, all config goes in `~/.codex/config.toml`. This is problematic for a few reasons: 1. It is not possible to set project-specific config that is automatically picked up; you must set a (globally accessible) profile and then start codex with that profile, or else type out a long command using `--config` with the same arguments each time. 2. It is not possible to share project-specific config with collaborators via VCS (possibly useful for sharin

Per-project config

Resolved 💬 6 comments Opened Sep 3, 2025 by rben01 Closed Nov 9, 2025

💡 Likely answer: A maintainer (bolinfest, collaborator) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Currently, all config goes in ~/.codex/config.toml. This is problematic for a few reasons:

It is not possible to set project-specific config that is automatically picked up; you must set a (globally accessible) profile and then start codex with that profile, or else type out a long command using --config with the same arguments each time.
It is not possible to share project-specific config with collaborators via VCS (possibly useful for sharing model providers and config).
Project-specific config such as [projects."/path/to/project"] trust_level = true have to live at a global level, which makes using VCS to sync one's global config.toml across machines problematic.

It would be better if, like with Claude Code, you could have a per-project .codex folder and within that, config.toml and config.local.toml, the former of which lives in VCS and the latter of which is in .gitignore and used just for oneself (this is where you can configure personal preferences like verbosity, reasoning level, etc). This way you could launch codex within a directory and be all set up with your preferences without having to specify a profile every time, and without having to write your profile in your global config. Also, truly project-specific settings such as trust_level would live there instead of globally. (For security, trust_level should probably only valid within config.local.toml so that a sneaky collaborator can't trick you intro trusting a folder by pushing a commit.)

Are you interested in implementing this feature?

Sure

Additional information

_No response_

View original on GitHub ↗

6 Comments

bolinfest collaborator · 11 months ago

@rben01 we hear you on this!

Certainly sharing config.toml files with a team via source control is a compelling feature, but as you touched on, there are safety concerns, such as someone pushing a malicious commit to config.toml or Codex itself modifying config.toml in a way that gives it escalated privileges on a subsequent invocation. We need to think through how we want to mitigate these risks before committing to a solution.

Though if you personally want to take on this risk today, one thing you could do is put a shared config.toml in some other folder and then add a wrapper script that runs codex with CODEX_HOME set to the folder containing the shared config.toml. It's admittedly not as clean as a first-party solution, but perhaps it can unblock you for now?

rben01 contributor · 11 months ago

For now I think that that idea will work. However, in theory I would also like project-specific config to merge with and override global config, effectively having a hierarchy of config files.

I also think it would be an improvement even just to have trust settings live in a different file in ~/.codex instead of ~/.codex/config.toml, again just to make the global config easier to use with VCS. This would also fix the issue with security and project-specific config.toml — trust settings just wouldn't exist in a project-specific file. (Other settings like sandboxing would still present a problem.)

jpcaparas · 11 months ago

https://github.com/openai/codex/issues/2628#issuecomment-3301944076

This is a good workaround until Codex adds official support for per-project config.toml

cemilcolak · 11 months ago

I implemented project-local configuration support for .codex. Now, the system first checks if a .codex directory exists in the current project folder and uses it as the configuration home. If not found, it falls back to the global CODEX_HOME environment variable or ~/.codex.

With this change:

Each project can have its own .codex/config.toml, .codex/auth.json, and other configuration files, isolating project settings from global settings.

Existing workflows remain compatible, as the global config is used when a project-local .codex folder does not exist.

Documentation has been updated to reflect this new behavior.

This addresses the request for project-specific configuration in Issue #3120. You can review the changes in PR #4007

Note: Adding .codex files to .gitignore is the developer's responsibility.

etraut-openai contributor · 9 months ago

Thanks for the feature request. I think this is captured in https://github.com/openai/codex/issues/2554, so I'm going to close this one and consolidate.

mesilov · 4 months ago

i have same problem =(