codex - 💡(How to fix) Fix Goal auto-continuations can downgrade Full Access threads to read-only/on-request while UI still shows Full Access

Summary

A Goal thread that is persisted and displayed as Full Access / no approvals can have automatic continuation turns launched with a read-only sandbox, on-request approvals, and a managed permission profile.

The visible state and persisted thread state indicate Full Access, but actual tool execution is restricted. This causes EPERM failures and approval paths during unattended Goal runs.

Environment

• Codex Desktop for macOS
• App version: 26.519.41501, build 3044
• Bundled CLI: codex-cli 0.133.0-alpha.1
• macOS: 15.7.4
• Goal feature enabled

What I expected

Goal automatic continuations should inherit the thread's effective permission context. If a Goal thread is Full Access with approvals disabled, its automatic continuation turns should also run with Full Access and no approvals.

Alternatively, if the runtime intentionally downgrades the permissions, the UI should show the effective downgrade before the continuation runs.

What happened

The thread metadata / persisted state showed Full Access:

thread_id=019e53bb-dda1-7ff3-ae85-3c3fd33b2119
sandbox_policy={"type":"danger-full-access"}
approval_mode=never

However, automatic Goal continuation turns in the rollout used a downgraded runtime context:

approval_policy=on-request
sandbox_policy={"type":"read-only"}
permission_profile=managed

This happened on automatic Goal continuation / resume turns, not on normal user-submitted turns.

Timeline / evidence

2026-05-24T05:44:39Z  approval_policy=never      sandbox_policy={"type":"danger-full-access"}  permission_profile=disabled
2026-05-24T05:46:33Z  approval_policy=on-request sandbox_policy={"type":"read-only"}          permission_profile=managed
2026-05-24T05:52:16Z  approval_policy=on-request sandbox_policy={"type":"read-only"}          permission_profile=managed
2026-05-24T05:54:21Z  approval_policy=on-request sandbox_policy={"type":"read-only"}          permission_profile=managed
2026-05-24T06:03:17Z  approval_policy=on-request sandbox_policy={"type":"read-only"}          permission_profile=managed
2026-05-24T06:24:09Z  approval_policy=on-request sandbox_policy={"type":"read-only"}          permission_profile=managed
2026-05-24T06:25:55Z  approval_policy=never      sandbox_policy={"type":"danger-full-access"}  permission_profile=disabled

The downgraded entries were automatic Goal continuations (summary=auto).

Error examples

Attempts to save local artifacts failed with EPERM during the downgraded Goal continuation turns, including a workspace file and temporary files:

EPERM: operation not permitted, open '<workspace-path>/29-current-debt-unpay-header-chain-field-final.png'
EPERM while writing /tmp/pf5665-write-test.txt
EPERM while writing /var/folders/.../pf5665-write-test.txt

A later command attempted to use an escalation path despite the UI/thread state indicating Full Access, and it failed as an approval rejection:

Rejected("rejected by user")

Impact

• Long-running Goal workflows become unreliable when unattended.
• The UI can say or imply Full Access while the actual runtime behaves like the default/read-only profile.
• The assistant may incorrectly ask for or attempt approvals in a thread that should not require them.
• File-producing tasks can stall on EPERM even when the thread was started and persisted as Full Access.

Related issues

This seems related to, but more specific than:

• #22090 (/goal continuation uses stale permission context after permissions changes)
• #23105 (Full Access /goal session falling back to sandboxed execution)
• #21839 (previously-existing Full Access sessions requiring approvals)

The distinguishing detail here is that the persisted thread state still shows danger-full-access / approval_mode=never, while automatic Goal continuation turn_context entries are actually launched as read-only / on-request / managed.