[macOS][ChatGPT Work 26.901.31953] request_permissions disappears after projectless task continuation while granular policy still requires it

Environment

• ChatGPT desktop app: 26.901.31953 (build 7868)
• Bundled codex-cli: 0.153.1
• macOS: 26.6.2 (25G83)
• Architecture: Apple Silicon / arm64
• Task type: local, projectless task
• Approval setting shown in the UI: Ask for approval

Problem

In an existing projectless task, per-path filesystem permission prompts worked earlier in the same conversation. Later, after the conversation continued in a new internal rollout, the approval policy still required the built-in request_permissions mechanism, but that tool was no longer exposed to the model.

This creates a permission deadlock for writes outside the workspace:

1. An ordinary write under ~/Downloads fails with Operation not permitted.
2. Retrying through the legacy shell escalation path is rejected before any prompt can be shown.
3. The built-in request_permissions tool, which the active granular policy expects, is absent from the available tool inventory.

There is no “Full access” setting in this UI/configuration, and the user did not change the approval setting.

Redacted diagnostic evidence

The current desktop log repeatedly reports:

requestApprovalPolicy={"granular":{"sandbox_approval":false,"rules":false,"skill_approval":false,"request_permissions":true,"mcp_elicitations":true}}
requestPermissionProfile=:workspace
requestRuntimeWorkspaceRootCount=2
requestSandboxWritableRootCount=0
useAppServerPermissionDefault=false

Attempting the legacy escalation path produces:

approval policy is Granular(GranularApprovalConfig {
  sandbox_approval: false,
  rules: false,
  skill_approval: false,
  request_permissions: true,
  mcp_elicitations: true
});
reject command — you cannot ask for escalated permissions

Earlier logs from this same conversation contain successful item/permissions/requestApproval responses granting write access to a subdirectory of ~/Downloads at:

• 2026-09-04 13:22:29 UTC
• 2026-09-04 14:54:24 UTC
• 2026-09-04 15:02:28 UTC

The earlier rollout contains 186 references to request_permissions; the current continuation contains none. The failure therefore correlates with the transition to a new internal rollout/continuation, while the granular policy itself remained active.

No sandbox, approval, or permission override is present in ~/.codex/config.toml.

Reproduction outline

1. Start a local projectless task with Ask for approval.
2. Perform an operation outside the workspace and approve a path through request_permissions.
3. Continue the same conversation until a new internal rollout/continuation is created (the exact lifecycle trigger is uncertain).
4. Request another write outside the workspace.
5. Observe that request_permissions is no longer available, while the policy still rejects the legacy sandbox_permissions=require_escalated path.

Expected behavior

Whenever the active granular policy has request_permissions: true, the built-in request_permissions tool should remain exposed across continuation, compaction, resume, or rollout transitions.

If it cannot be exposed, the runtime should provide a compatible approval fallback instead of leaving no valid authorization path.

Actual behavior

The task cannot request the user's authorization at all. It can read the source and determine the exact write needed, but it cannot create the requested backup under ~/Downloads.

Related issues

• #32563 — similar projectless-task deadlock involving Ask for approval
• #34182 — similar approval behavior changing during an existing desktop session
• #23359 — granular policy/model escalation mismatch

This report adds a current macOS reproduction and evidence that the required tool was available earlier and then disappeared within the same conversation.

Privacy

Paths, usernames, task identifiers, external-volume names, and user data have been redacted. No raw logs or personal files are attached.

Start by reproducing the projectless-task continuation flow with the granular policy and inspect the request_permissions tool inventory across rollout or resume transitions. Compare it with the legacy sandbox escalation path and the logged approval policy. Done means request_permissions remains available when required, or a compatible authorization fallback prevents the deadlock.