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:
- Allows config.toml sharing on multiple machine / multiple platforms.
- Easy to reason about. Generic enough to cover other / future configs.
- User can add machine depending config to it. Say, user can enable notification in macOS but not in headless VPS.
Additional information
_No response_
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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:
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:
Then, if host-aware selection is still needed later, it could live inside that local file where it remains private to the machine/user.