Claude settings migration prompt clobbers user-level config.toml when no project-level config exists

Summary

When Codex presents the "migrate Claude settings" prompt and the user accepts, it writes values into ~/.codex/config.toml (user-level) even when there is no project-level .codex/config.toml. In doing so it overwrites existing user-level settings — in my case flipping approvals_reviewer from guardian_subagent to user, which caused Codex to prompt for approval on every routine command.

Environment

• Codex CLI 0.133.0
• macOS arm64
• Auth: ChatGPT login (anders.swanson@dbtlabs.com)
• ~/.codex/config.toml exists and is fully configured
• No .codex/config.toml at the project level

Reproduction steps

1. Have a user-level ~/.codex/config.toml with approvals_reviewer = "guardian_subagent" (or any non-default value).
2. Open Codex in a project directory that has a Claude Code config (e.g. .claude/settings.json) but no .codex/config.toml.
3. Accept the "migrate Claude settings" prompt when it appears.
4. Observe that ~/.codex/config.toml is now modified — specifically approvals_reviewer has been reset to "user" and a [notice.external_config_migration_prompts] section has been appended.

Observed behavior

• approvals_reviewer = "guardian_subagent" → overwritten to approvals_reviewer = "user"
• Every subsequent Codex command prompts for user approval (the guardian_subagent reviewer had been silently handling routine approvals)
• The diff from git restore shows the migration touched approvals_reviewer, [notice.external_config_migration_prompts], and several formatting/whitespace changes

Expected behavior

Two separate issues here (either fix would help):

1. Don't show the migration prompt at all when there is no project-level .codex/config.toml. If there's no project config to write into, there's nothing to migrate — the user-level config should be left untouched.

1. If the migration does run, don't overwrite keys the user has already set in their user-level config. The migration should only write keys that are missing, not reset existing values to defaults.

Why this matters

approvals_reviewer = "guardian_subagent" is a deliberate power-user setting. Silently resetting it to "user" is a high-impact change — it turns every shell command into an interactive approval prompt with no visible indication of what changed or why. Users with managed/symlinked dotfiles (like me, where ~/.codex/config.toml → dotfiles/.codex/config.toml) may not notice the unstaged diff until they've spent time debugging unexpected behavior.

Related

Issue #24065 describes a similar config-clobbering problem triggered by the marketplace refresh; the root cause here is different (migration prompt path) but the symptom is the same.