Reject legacy [profiles] when using profile-v2

[jif-oai]

Why

profile-v2 layers the selected profile file on top of the base user config.toml, but the legacy [profiles] table also stores named profile overrides in that same base file. Allowing both paths during one load makes it too easy to get a mixed profile where stale legacy settings still influence a profile-v2 run.

What Changed

• Detect a legacy [profiles] table in the base user config whenever --profile-v2 selects a profile file.
• Fail config loading with an InvalidData error that tells the user to move those settings into the selected profile-v2 file or remove [profiles].
• Add a loader regression covering --profile-v2 with legacy [profiles] in config.toml.

Testing

• cargo test -p codex-config profile_v2_rejects_legacy_profiles_in_base_user_config

[jif-oai]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

ℹ️ 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".

[etraut-openai]

This looks reasonable, but it seems to go beyond the stated intent in the PR notes. Notably, it generates an error even if there's a latent, uncommented [profile] left in the config even if it's not selected. That means users who want to try --profile-v2 will need to comment out all of their existing profiles. I don't have a strong opinion here, but you might want to consider allowing unreferenced [profile] entries to not generate an error.

Here's a manual test case that I used to repro this behavior.

cat > "$tmp/config.toml" <<'EOF'
model = "gpt-main"

[profiles.old]
model = "gpt-legacy"
EOF

CODEX_HOME="$tmp" cargo run -p codex-cli -- --profile-v2 work