Separate project trust state from ~/.codex/config.toml so global config can be VCS-managed

What feature would you like to see?

Please separate project trust state from ~/.codex/config.toml.

Today, project trust is stored in the global config via entries like:

[projects."/absolute/path/to/repo"]
trust_level = "trusted"

This makes ~/.codex/config.toml hard to manage in version control across machines.

Why this matters

A common setup is to keep ~/.codex under VCS for disaster recovery / machine rebuilds / dotfiles sync.

That works well for stable configuration such as:

• model defaults
• MCP settings
• instructions / rules / skills / knowledges

But project trust state is different:

• it is local-machine state
• it is path-dependent
• it changes at runtime
• it often contains absolute paths

As a result, config.toml mixes two different concerns:

1. shareable/static configuration
2. local/mutable trust state

That creates several problems:

• noisy diffs in a VCS-managed ~/.codex/config.toml
• stale absolute paths when syncing to another machine
• hard to keep global config portable across machines
• no clean way to exclude trust state without excluding the whole config file

Suggested solution

Move trust state into a separate local file, for example:

~/.codex/trust_level.toml

or similar (trust.toml, trust-state.toml, etc.).

Then:

• keep ~/.codex/config.toml for stable user configuration
• keep trust state in a separate machine-local file
• let Codex update that trust file automatically when trusting/untrusting projects
• continue treating trust as local-only state

This would let users safely VCS-manage most of ~/.codex while excluding only the trust file.

Why repo-local config does not fully solve this

Workspace/project config support already exists, but project-scoped .codex/config.toml is only loaded for trusted projects.
That means the trust gate itself still has to live outside the repo-level config.

So even with workspace config support, the remaining pain point is that trust_level is still coupled to the global config file.

Related issues

• #2554
• #5160

From my perspective, those issues addressed or discussed workspace-level config and machine-shareable config, but the unresolved core problem is still:

trust state is local mutable state, and should not be stored in the same file as shareable global configuration.

Additional information

I tested this locally and found that projects.<path>.trust_level still behaves like path-matched local trust state.
That reinforces the idea that it belongs in a separate local trust store rather than in a VCS-managed global config file.