Codex Desktop silently rewrites autonomy settings, causing projectless .codex EPERM prompts

Summary

Codex Desktop silently rewrote the machine-wide autonomy tuple in ~/.codex/config.toml from:

approval_policy = "never"
sandbox_mode = "danger-full-access"
approvals_reviewer = "user"

to:

approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "guardian_subagent"

Fresh projectless threads then inherited the restricted profile. Their generated workspace root was writable, but the reserved .codex child was explicitly read-only, so ordinary goal-artifact creation failed with Operation not permitted and agents requested escalation for basic local setup.

This is separate from #32039 (projectless root symlink validation). The projectless root was already repaired to a real local directory and task creation itself succeeded.

Environment

• Codex Desktop: 26.707.61608 (build 5200)
• Codex CLI: 0.144.3
• macOS: 26.5.2 (build 25F84)
• Architecture: Apple Silicon (arm64)

Evidence

• A pre-incident config backup has never / danger-full-access / user.
• The rewritten config.toml had a filesystem birth/modification time of 2026-07-13 07:10:14 -0300, the exact second one affected projectless thread was created.
• Other bounded config backups all retain the intended tuple.
• Two affected projectless thread turn_context records show:
• approval_policy: on-request
• sandbox_policy.type: workspace-write
• managed permission profile
• workspace root writable
• workspace .codex read-only
• The first ordinary mkdir -p .codex/<goal> in each affected thread returned Operation not permitted.
• Direct create_goal calls later succeeded; the approval request was caused by the filesystem profile/path collision, not the goal API itself.
• After restoring never / danger-full-access / user, two fresh projectless canaries started with permission_profile: disabled, created .codex/<goal>/goal.md and plan.md, activated/completed goals, made ordinary local edits, and finished with no approval prompt.
• No installed LaunchAgent or local maintenance script writes these settings. The exact writer is not represented by a session-level patch event, so attribution to a specific Desktop code path remains uncertain.

Observed sequence

1. Configure ~/.codex/config.toml with never / danger-full-access / user.
2. Use Codex Desktop to create projectless threads.
3. Observe that config.toml has been atomically replaced with on-request / workspace-write / guardian_subagent.
4. In a fresh projectless thread, attempt ordinary workspace-local state under .codex/<name>.
5. Observe EPERM and an escalation request.

The rewrite was not reproduced on every subsequent projectless creation, so this may depend on a settings migration or a one-time Desktop persistence path.

Expected behavior

Codex Desktop updates must preserve explicit user autonomy settings in ~/.codex/config.toml. Creating a projectless task must not silently replace them.

If Desktop intentionally migrates or overrides these fields, it should:

• expose the change clearly;
• preserve an explicit existing user choice;
• avoid making a projectless workspace's required local state path read-only; and
• never turn ordinary projectless goal setup into a user approval prompt.

Local mitigation

I restored the intended tuple and installed a narrow event-driven guard that backs up the config and repairs only the exact known-bad triple. This protects the local workflow but does not fix the underlying Desktop write.