Windows Desktop: thread access mode silently reverts from Full access to workspace-write on thread reopen / app restart #36497

Summary

On Codex Desktop for Windows, a thread's granted access level ("Full access" / danger-full-access + approval_policy: never) is not persisted with the thread. Whenever the thread is reopened or the app restarts, subsequent turns are silently sent with the default workspace-write sandbox and approval_policy: on-request. The user, believing full access is still in effect, then gets repeated approval prompts for commands and MCP tool calls that previously ran without prompts — including re-prompts for MCP actions that were already approved earlier in the same thread.

Environment

• Codex Desktop for Windows (Store package OpenAI.Codex_26.727.6591.0_x64), CLI core 0.146.0-alpha.9.2
• Also observed with standalone CLI codex-cli 0.146.0
• Windows 11 Home 10.0.26200

Evidence (from the thread's rollout turn_context records)

A single long-running thread shows the access level flapping in lockstep with app/thread reopen events, never with an explicit user change:

line 10027  2026-07-17T07:56:14  approval=never       sandbox=danger-full-access
line 11540  2026-07-17T09:06:24  approval=never       sandbox=danger-full-access
line 12261  2026-07-17T19:25:37  approval=on-request  sandbox=workspace-write      <- thread reopened
line 12571  2026-07-28T04:20:31  approval=never       sandbox=danger-full-access   <- user re-granted
line 13657  2026-07-28T05:24:10  approval=never       sandbox=danger-full-access
line 14378  2026-07-31T18:01:30  approval=on-request  sandbox=workspace-write      <- thread reopened
line 14725  2026-08-01T09:17:19  approval=on-request  sandbox=workspace-write      <- app restart
line 15257  2026-08-01T14:36:44  approval=on-request  sandbox=workspace-write

Additionally, some post-reversion turns carry a workspace-write policy whose writable_roots is only the thread's visualizations directory (~/.codex/visualizations/<date>/<thread-id>), with network_access: false — so effectively every repo write and every network command escalates, producing an approval prompt storm.

Repro

1. In Codex Desktop on Windows, start a thread and grant Full access; run a few commands (no prompts — expected).
2. Close and reopen the thread (or restart the app).
3. Send another message that runs a command outside the default workspace-write sandbox.
4. Observe an approval prompt. Inspect the session rollout: the new turn_context shows approval_policy: on-request / workspace-write even though the UI gave no indication the grant was dropped.

Expected

Either the thread's granted access level persists across reopen/restart, or the UI clearly indicates that access has reverted to the default before the next message is sent.

Actual

Access silently reverts; the user discovers it only via unexplained approval prompts (including for previously approved MCP tools). Diagnosing required reading the rollout JSONL directly.

Impact

Long-running agent threads (ours run for weeks) degrade into approval storms after every app update/restart, and users may conclude approvals are broken rather than that the grant was dropped.