Codex Desktop 26.715: active Goal reverts from Full Access to on-request after account switch/resume

Summary

Codex Desktop can restore an active long-running Goal with stale per-thread permission state after switching ChatGPT accounts. In my case, I explicitly selected Full Access, but the affected thread was written back from approval_policy=never / danger-full-access to approval_policy=on-request / workspace-write 18.7 seconds later. The Goal then resumed asking for file approvals repeatedly.

This started only after switching accounts. Before the account switch, the same long-running Goal did not have this problem.

Environment

• ChatGPT/Codex Desktop: 26.715.21425 (build 5488)
• Bundled Codex CLI: 0.145.0-alpha.18
• Affected thread was originally created with CLI 0.144.2
• macOS 26.5.2 (25F84), Apple Silicon
• Subscription: Pro 20x on each of three separate paid accounts
• Affected thread: 019f65bc-5783-73c2-aaad-5aca5b01e239

Why account switching is unavoidable for me

Frankly, this is extremely frustrating. I have three separate paid Pro 20x accounts because the usage allowance on one account is not enough for my long-running research and coding workloads. When one account runs out of quota, I have to switch to another paid account to continue working.

After switching, a Goal that is supposed to run autonomously turns into a workflow where I have to babysit a file-approval dialog repeatedly. Paying for three Pro 20x accounts and still being blocked by stale permission state every time I switch accounts is a terrible experience. Account switching is not an edge-case convenience for my workflow; it is necessary because of the available usage limits.

Observed behavior

1. A long-running Goal was working normally before the account switch.
2. I switched ChatGPT accounts after reaching the available usage allowance.
3. I resumed the existing thread and Goal.
4. I selected Full Access.
5. The thread briefly received the correct Full Access settings.
6. Less than 19 seconds later, the client submitted ThreadSettings that restored on-request, user, and workspace-write.
7. I then selected Approve for me, but that only changed approvals_reviewer to auto_review; the effective policy remained on-request.
8. The Goal continued surfacing manual file-edit approval dialogs.

The current persisted state for the affected thread is:

approvalPolicy: on-request
approvalsReviewer: auto_review
sandboxPolicy: workspaceWrite

This is not Full Access.

Local timeline and evidence

All timestamps below are Asia/Shanghai on 2026-07-18:

01:12:13  auth.json updated at the account-switch boundary
01:15:40  ThreadSettings: on-request + user + workspaceWrite
01:15:55  ThreadSettings: on-request + auto_review + workspaceWrite
01:21:14  README.md PatchApproval -> ApprovedForSession
01:21:18  ThreadSettings: on-request + user + workspaceWrite
01:30:22  a new app-server process performs thread/resume for the affected thread
01:32:47  ThreadSettings: never + Disabled + :danger-full-access
01:33:05  ThreadSettings: on-request + user + workspaceWrite
01:34:31  ThreadSettings: on-request + auto_review + workspaceWrite
01:34:27  file A PatchApproval -> ApprovedForSession
01:35:12  README.md PatchApproval -> ApprovedForSession
01:35:58  file B PatchApproval -> Approved
01:36:56  file C PatchApproval -> ApprovedForSession
01:37:37  README.md edited again without another PatchApproval

The 01:32:47 -> 01:33:05 transition is the core bug: the thread was explicitly placed in Full Access and then received stale restrictive settings 18.7 seconds later.

The app-server process also changed before thread/resume, rebuilding the live session. That explains why a file approved earlier in the previous live session could prompt again after resume.

Important distinction: this is not merely the per-file approval scope

I checked the implementation corresponding to the bundled CLI version. ApplyPatchApprovalKey is keyed by environment_id + path, and ApprovedForSession for file changes applies to the same files, not every file in a directory.

Therefore, different files prompting separately under on-request is consistent with the current implementation, even though the UI label "Allow all changes" is confusing.

The evidence above also shows that the per-file cache worked within the rebuilt live session: after approving README.md at 01:35:12, another edit to that same file at 01:37:37 did not prompt again.

The bug reported here is the stale thread/Goal permission state after account switching and resume, which unexpectedly puts the thread back into on-request in the first place.

Expected behavior

• Switching accounts and resuming a thread must not silently replace its current Full Access selection with stale on-request settings.
• An active Goal should inherit the latest effective thread permission context.
• If permissions must be reset after an account switch, the UI should show that explicitly and require a deliberate user choice before the Goal resumes.
• Selecting Approve for me should not leave the UI implying that the Goal can continue unattended when the effective policy can still surface repeated user prompts.

Reproduction steps

1. Start a long-running Goal in Codex Desktop under account A.
2. Set the thread to Full Access or Approve for me and allow it to run normally.
3. After reaching the account's usage allowance, switch to another paid Pro account.
4. Resume the same existing thread and active Goal.
5. Select Full Access.
6. Continue or resume the Goal.
7. Observe whether the effective thread state returns to on-request / workspace-write and file approval dialogs begin appearing.

Current workaround

The workaround suggested in related reports is to change permissions, send one ordinary non-Goal user prompt so a normal turn applies the settings, and only then create or resume the Goal.

For this affected thread, the more reliable workaround is to create a completely new thread, set permissions, send a normal turn, verify the effective state, and only then create a new Goal. That loses the continuity and context of the long-running Goal, so it is not an acceptable permanent solution.

Related issues

• #21839 - Previously-existing sessions with full access require approvals
• #22090 - /goal continuation uses stale permission context after permissions changes
• #29693 - /goal continuation can reuse stale permission context after Full Access/custom permissions
• #17016 - account switching can cause configured settings to fall back to defaults
• #17623 - saved approval scope is not clearly explained in the UI

This report adds a current macOS Desktop 26.715.21425 reproduction tied specifically to account switching, an active long-running Goal, an app-server thread/resume, and a timestamped Full Access -> on-request rewrite.