Easily share user preferences across machines

Open 💬 3 comments Opened Feb 8, 2026 by mattmorgis

What variant of Codex are you using?

CLI

What feature would you like to see?

I use Codex on multiple machines and want consistent user-level preferences (model, sandbox policy, MCP servers, etc.).

Today ~/.codex/config.toml mixes user preferences with local trust entries, which makes it non-portable when managed via dotfiles.

Example:
My base config that I sync to ~/.codex/config.toml on all of my machines:
https://github.com/mattmorgis/.dotfiles/blob/main/config/codex/config.toml

But Codex appends per repo trust entries to ~/.codex/config.toml:

[projects."/Users/matt/.dotfiles"]
trust_level = "trusted"

Instead of being able to symlink or copy the file cleanly when I update it, I ended up writing a sync script that overwrites the base config and re-attaches [projects.*] blocks:
https://github.com/mattmorgis/.dotfiles/blob/main/scripts/codex-sync.sh

Would it be possible to make user-level preferences portable across machines?

One easy way to achieve this behavior would be to move the per-project trust entries into a separate file (e.g. ~/.codex/trust.toml or ~/.codex/config.local.toml)? That would make config.toml sharable across machines.

Happy to help implement the preferred approach once there is alignment.

Additional information

_No response_

View original on GitHub ↗

3 Comments

flexdinesh · 5 months ago

This change would be heaps helpful. Backlinking my comment from a related issue with an example of how the current config makes it difficult to share config between different machines.

https://github.com/openai/codex/issues/14601#issuecomment-4114297437

nkeat12 · 4 months ago

sessions should sync too

coygeek · 4 months ago

+1 — running into this across 3 machines (different usernames on each) sharing ~/.codex via a private git repo. Adding concrete evidence in case it helps unstick this.

Empirical test: `~` is treated as a literal path

Tested on codex-cli 0.123.0, macOS 25.4.0, by hand-editing this into the shared config:

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

Running codex from $HOME still triggers the trust prompt. Approving it appends [projects."/Users/<username>"] back to config.toml, and the resulting diff is now waiting to be committed to the shared repo — the exact ping-pong this issue is about.

The fix appears localized

The infrastructure for ~-expansion already exists in the Rust source and is used for other path fields:

AbsolutePathBuf::maybe_expand_home_directory() in codex-rs/utils/absolute-path/src/lib.rs — expands ~/ during deserialization for AbsolutePathBuf-typed fields (e.g. workspace_write_roots).
expand_tilde_path() in codex-rs/core-plugins/src/marketplace_add/source.rs — expands ~/ when reading a marketplace source, so a user-written source = "~/..." resolves correctly.

What's missing:

project_trust_key() in codex-rs/core/src/config_loader/mod.rs uses a raw path.to_string_lossy() — no home expansion, so [projects."~"] never matches $HOME.
set_project_trust_level_inner() in codex-rs/config/src/lib.rs writes the absolute path verbatim when Codex approves a trust prompt.
record_added_marketplace_entry() in codex-rs/core-plugins/src/marketplace_add/metadata.rs writes marketplace source as path.display().to_string() — so even if a user writes ~/ by hand, the next marketplace refresh rewrites it to an absolute path.

Two tractable fixes

Read-side expansion for [projects."<key>"] — apply maybe_expand_home_directory() when comparing a project path against the trust map. Shortest patch; immediately unlocks [projects."~"] and [projects."~/code"] for VCS-managed config.
Write-side canonicalization — when Codex auto-writes trust or marketplace entries, rewrite $HOME back to ~/ before serialization so the round-tripped config stays portable.

Doing (1) alone unlocks the dotfiles use case for users who hand-edit their shared config. Doing (1) + (2) closes the ping-pong completely.

Related: #14601 covers the narrower trust-entry-only version of this.