WSL CLI 0.146.0: restoring Full Access on startup rewrites approvals_reviewer from auto_review to user

Summary

On Codex CLI 0.146.0 under WSL, starting a TUI session with Full Access selected or restored silently rewrites the top-level setting:

approvals_reviewer = "auto_review"

in ~/.codex/config.toml to:

approvals_reviewer = "user"

The captured mutation happened during startup before any user message was sent. This appears to be a regression or an incomplete fix of #19297 / #19256.

Environment

• Codex CLI: 0.146.0
• Surface: interactive CLI/TUI
• Platform: WSL Ubuntu on a Windows 10 host
• Model in the captured session: gpt-5.6-sol (likely unrelated)

Steps to reproduce

1. Set the top-level reviewer in ~/.codex/config.toml:

``toml
approvals_reviewer = "auto_review"
``

1. Start the Codex TUI with Full Access selected or restored.
2. Do not send a prompt or change the permission mode.
3. Inspect ~/.codex/config.toml during or immediately after startup.
4. Observe that the top-level value has changed to:

``toml
approvals_reviewer = "user"
``

The problem was originally noticed after Codex or WSL crashes because a restart makes the unexpected change visible, but the recorded write itself occurred in the TUI startup/settings path.

Sanitized trace evidence

The app-server trace showed the following sequence within milliseconds:

thread/settings/update
ThreadSettings {
  approval_policy: Never,
  approvals_reviewer: User,
  permission_profile: Disabled,
  ... Full Access ...
}
config/batchWrite

The modification time of config.toml changed at the same point. The new thread contained no user-message event before the write.

Raw logs are not attached because they contain local paths and session identifiers. The excerpt above contains only event and setting names.

Expected behavior

Selecting or restoring Full Access may change the effective settings for the active session, but it should not overwrite an explicit global approvals_reviewer preference.

Even though the reviewer is not used while approval_policy = "never", its persisted value still matters when the user later returns to a restricted or on-request permission mode.

Actual behavior and impact

The Full Access initialization path persists approvals_reviewer = "user" globally. Later sessions then show manual approval prompts instead of routing eligible requests through auto-review.

Because this commonly becomes visible after a restart, it looks as though Codex or WSL randomly reset the user's permission preference.

Related issues

• #19297 reports nearly the same persisted config mutation in CLI 0.124.0 and was closed as a duplicate.
• #19256 was closed as completed, with a maintainer stating that the fix would be in the next release.
• #23875 is related but distinct: it covers losing the reviewer in runtime context after compaction/resume rather than rewriting config.toml.

Local workaround

A narrow launcher guard restores only the top-level approvals_reviewer value before startup and also passes a runtime config override. This prevents the symptom locally but does not address the underlying persistence path.