Make confg.toml sharable across machines

Resolved 💬 13 comments Opened Oct 14, 2025 by KaminariOS Closed Jan 30, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Currently, my config.toml looks like this:

[projects."/tmp"]
trust_level = "trusted"

[projects."/tmp/spring-demo"]
trust_level = "trusted"

[projects."/tmp/kafka_test"]
trust_level = "trusted"

[tools]
web_search = true

Codex modifies it at runtime.

This is not ideal if my config.toml is managed by Git.

When I push my config.toml and other dotfiles to Github, I do not want to have those trust_level.

Additional information

_No response_

View original on GitHub ↗

13 Comments

etraut-openai contributor · 8 months ago

The config.toml file is not stored within your project workspace, so if you're using the default sandbox policy, the model cannot modify it without your approval. We have received many requests for supporting a project-local config.toml, but this poses a security / sandboxing challenge.

zeyugao · 8 months ago

@etraut-openai it is not related to the sandbox at all

The codex itself will mark a workspace as trusted when we enter a new folder, it is what "Codex modifies it at runtime." means.

What we want is to keep these trusted workspace in a new file such as ~/.codex/trusted.toml, so that trusting a new workspace will not affect the config.toml which is synced with git across different machines. As in different machine we will have different trusted workspaces.

KaminariOS · 8 months ago

Yes, this is what I meant.

It should be trivial to separate them.

Just ask codex to do it.

@etraut-openai it is not related to the sandbox at all The codex itself will mark a workspace as trusted when we enter a new folder, it is what "Codex modifies it at runtime." means. What we want is to keep these trusted workspace in a new file such as ~/.codex/trusted.toml, so that trusting a new workspace will not affect the config.toml which is synced with git across different machines. As in different machine we will have different trusted workspaces.

connorads · 6 months ago

+1 on this. I manage my ~/.codex/config.toml via dotfiles (synced across multiple machines) and the [projects] entries with absolute paths like /Users/myuser/git/project break portability.

Separating trust to a separate file (e.g. trusted.toml) would solve this nicely.

Alternatively, supporting tilde (~) or environment variable expansion ($HOME) in project paths would also help:

[projects."~/git"]
trust_level = "trusted"

Either approach would make config.toml portable across machines.

etraut-openai contributor · 5 months ago

Codex now supports project-local .codex/config.toml files.

bohrshaw · 5 months ago

This issue is actually about the trust_level setting. And it's never written to a project-local .codex/config.toml file.

srstevenson · 5 months ago

codex-cli 0.98.0 still writes project trust_levels to ~/.codex/config.toml, and not a project local .codex/config.toml file or elsewhere, and ~/.codex/config.toml remains non-portable across machines.

etraut-openai contributor · 5 months ago

@srstevenson, the ~/.codex/config.toml file isn't designed to be used across machines. We did recently add support for project-local config.toml overrides. Those are designed to be checked in to projects and used across machines.

writeonlymemory · 5 months ago

@etraut-openai that's not helpful in the case of a single developer using multiple machines. I don't want every root I trust on my laptop trusted on my desktop, for example.

srstevenson · 5 months ago

@etraut-openai Thanks for the clarification that ~/.codex/config.toml is currently intended to be machine-local.

My motivation is that there are user‑level preferences that I want to apply consistently across all machines, without committing them in every repo. For example, I want Codex to use the same model everywhere, but I don't want to duplicate that config key across every repo on every machine, especially if other contributors don't use Codex (and even if they do, they may prefer a different model). That's why having machine-level state in a separate file from user‑level configuration would be helpful.

etraut-openai contributor · 5 months ago

I think there's a real feature request buried in this thread, but the way it was phrased by the OP is problematic because it proposes a specific solution that we are unlikely to implement.

Let's focus on the problem / need rather than a specific solution. I'd appreciate it if someone could open a new feature request that explains the use case and desired behavior.

writeonlymemory · 5 months ago

@etraut-openai

I think there are actually two feature requests:

I want host specific preferences
@srstevenson wants user preferences [I do, too, of course]

The current behavior of putting both host [trusted roots] and user level [models, notices, etc] preferences in config.toml in the home directory precludes either of these things from working properly.

I'll file a feature request if no one beats me to it.

mattmorgis · 5 months ago

@etraut-openai there is!

I took a pass at requesting the user preferences (and how I'm currently working around it) here: #11061