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

Start by tracing the rollout JSONL turn_context records across thread reopen and app restart, comparing the persisted access grant with the next turn's sandbox and approval policy. Reproduce the Windows Desktop flow in the issue and verify that the grant persists, or that the UI clearly reports a reversion before sending a turn.

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.