Some alternative improvement proposal on the config.toml

Open 💬 2 comments Opened Jun 3, 2026 by hktonylee
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App, CLI

What feature would you like to see?

I'd like to propose to add [overrides.<machine-name>.<config-key>] support to the config.toml. This will have a higher precedence over [<config-key>] in the config.toml if the <machine-name> matches the current machine. And we disallow <config-key> to be overrides.

This has these pros:

  1. Allows config.toml sharing on multiple machine / multiple platforms.
  2. Easy to reason about. Generic enough to cover other / future configs.
  3. User can add machine depending config to it. Say, user can enable notification in macOS but not in headless VPS.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #24961

Powered by Codex Action

SylvainWinning · 2 months ago

I think this is a useful variant of the config-scoping problem, but I would be cautious about making the machine name the primary selector.

The closest related issue flagged by the bot, #24961, asks for a gitignored project-local override layer. That model seems to cover many of the same use cases here while avoiding a few machine-name edge cases:

  • hostnames can change or collide, especially in corporate/VM/CI environments;
  • committing machine names into a shared config can leak personal or infrastructure details;
  • a project may need multiple local profiles on the same machine, not just one override keyed by host;
  • precedence debugging is easier if the override is a real config layer visible in config/read / debug output, rather than a conditional subtree inside the same file.

A possible compromise would be to treat machine-specific overrides as a future extension on top of explicit config scopes, not the first primitive. The MVP could be:

.codex/config.toml         # shared project defaults
.codex/config.local.toml   # gitignored local override, higher precedence

Then, if host-aware selection is still needed later, it could live inside that local file where it remains private to the machine/user.