feat: add layered --profile-v2 config files#17141
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
codex/codex-rs/app-server/src/lib.rs
Line 433 in 330e49a
Preserve profile-v2 path in fallback config load
When ConfigBuilder fails, app-server falls back via Config::load_default_with_cli_overrides(...), which drops loader_overrides.user_config_path. Later ConfigEditsBuilder::for_config(&config) resolves to $CODEX_HOME/config.toml, so sessions started with --profile-v2 can persist edits (e.g. skills/tool approvals) into the wrong file after an invalid selected config.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
# Conflicts: # codex-rs/app-server/src/config_manager_service.rs # codex-rs/tui/src/app/tests.rs
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
# Conflicts: # codex-rs/app-server-protocol/src/protocol/v2.rs # codex-rs/config/src/state.rs # codex-rs/core/src/mcp_tool_call_tests.rs # codex-rs/core/src/session/mod.rs # codex-rs/tui/src/app/event_dispatch.rs
# Conflicts: # codex-rs/tui/src/app/event_dispatch.rs
bolinfest
left a comment
bolinfest
left a comment
There was a problem hiding this comment.
Mostly small issues which you can take or leave, though one thing I do feel is important is using ProfileV2Name instead of String wherever appropriate.
I realize now that in some of my comments, String may be used because it is still referring to profile v1, so I guess those can't be converted right now. (Or maybe we do and run the risk of breaking folks who decided to create profiles in config.toml that have names with characters we don't allow, which I think is acceptable.)
| @@ -261,49 +323,92 @@ impl ConfigLayerStack { | |||
There was a problem hiding this comment.
Docstring needs to be updated to explain what happens when there are multiple user layers?
# Conflicts: # codex-rs/app-server/tests/suite/v2/config_rpc.rs # codex-rs/cli/src/main.rs # codex-rs/config/src/loader/mod.rs # codex-rs/core/src/config/mod.rs # codex-rs/core/src/mcp_tool_call_tests.rs # codex-rs/exec/src/lib.rs # codex-rs/tui/src/lib.rs
jif-oai
changed the title
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
2 participants
Why
--profile-v2 <name>gives launchers and runtime entry points a named profile config without making each profile duplicate the base user config. The base$CODEX_HOME/config.tomlstill loads first, then$CODEX_HOME/<name>.config.tomllayers above it and becomes the active writable user config for that session.That keeps shared defaults, plugin/MCP setup, and managed/user constraints in one place while letting a named profile override only the pieces that need to differ.
What Changed
--profile-v2 <name>runtime option with validated plain names, now represented byProfileV2Name.Userlayers; APIs expose the active user layer and merged effective user config.codex,codex exec,codex review,codex resume,codex fork, andcodex debug prompt-input.Limits
--profile-v2is still rejected for config-management subcommands such as feature, MCP, and marketplace edits. Those paths remain tied to the baseconfig.tomluntil they have explicit profile-selection semantics.Some adjacent background writes may still update base or global state rather than the selected profile:
Verification
Added targeted coverage for profile name validation, layer ordering/merging, selected-profile writes, app-server config writes, session hot reload, plugin config merging, hooks/config fixture updates, and MCP/app approval persistence.