Windows Desktop changes an existing Ask for approval task from on-request to granular mid-session

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.715.4045.0, bundled command runner 0.145.0-alpha.18.

What subscription do you have?

Education

What platform is your computer?

Windows 11 x64

What issue are you seeing?

An existing general-chat/projectless task changed from working approval_policy=on-request behavior to an explicit granular policy between turns, while the UI continued to show Ask for approval and no permission-mode change was made:

GranularApprovalConfig {
    sandbox_approval: false,
    rules: false,
    skill_approval: false,
    request_permissions: true,
    mcp_elicitations: true
}

After the transition, commands using sandbox_permissions="require_escalated" were rejected before an approval prompt could be created.

This has the same lower-level policy failure as #32563, but a different lifecycle. That report deterministically reproduces the policy in a newly created projectless task. Here, the same existing task first used OnRequest successfully and then Desktop changed its outgoing permission request between two later turns.

The Desktop log records the transition:

11:09:48.561Z requestApprovalPolicy=null
             resolvedApprovalPolicy=on-request
             useAppServerPermissionDefault=true

11:32:30.296Z requestApprovalPolicy={granular:{sandbox_approval:false,...}}
             requestPermissionProfile=:workspace
             useAppServerPermissionDefault=false

The session rollout independently records thread_settings_applied with on-request at 11:09:48.765Z and the granular policy at 11:32:30.721Z, for the same task and working directory.

The renderer therefore supplied the granular override explicitly; the command runner did not spontaneously convert OnRequest.

Two suspected triggers occurred later and can be excluded:

• The rollout's compacted event occurred at 11:33:54Z, approximately 84 seconds after the granular profile was active.
• Denial of an unrelated in-app browser request also occurred after the transition.

The task could be toggled between the two behaviors. Approve for me restored on-request with approvals_reviewer=auto_review; switching back to Ask for approval immediately restored sandbox_approval:false and the pre-prompt rejection.

After two Desktop restarts, the same task again used ordinary on-request approval and an elevated command successfully reached a user prompt. Its persisted Desktop record was then healthy: approvalPolicy="on-request", approvalsReviewer="user", and no active granular profile.

The failure later recurred in this same existing task. A normal GitHub CLI network command was blocked by the sandbox, and its require_escalated retry was again rejected before prompting with the granular profile above. This demonstrates that restart can temporarily restore the task while a later turn can reintroduce the bad policy.

What steps can reproduce the bug?

The exact event that changes the existing task's renderer state is not yet isolated, but the observed sequence is:

1. Open an existing general-chat/projectless task with Ask for approval selected.
2. Confirm that its effective policy is on-request and that an escalated command can produce an approval prompt.
3. Continue the same task across later turns without changing the permission mode.
4. Observe that Desktop eventually starts a turn with an explicit granular requestApprovalPolicy and useAppServerPermissionDefault=false.
5. Retry an otherwise identical command with sandbox_permissions="require_escalated".
6. Observe that it is rejected before prompting because sandbox_approval=false.
7. Restart Desktop and observe that the same task may return to on-request, then later regress again.

What is the expected behavior?

An existing task should not silently change its effective permission model between turns or app restarts.

Ask for approval should either preserve the established on-request command-approval flow or expose a complete and consistent granular-permission contract. In particular, Desktop should not leave an existing task and its agent with an escalation interface that is guaranteed to be rejected before the user can be asked.

Additional information

Related reports:

• #32563 covers the same policy failure for newly created projectless tasks.
• #33322 covers a separate task-profile persistence symptom in which a task becomes read-only; its permission-mode toggle repairs the sandbox instead of deterministically reselecting sandbox_approval:false.
• #23359 covers the lower-level granular policy and tool-schema mismatch.

The relevant redacted Desktop log and rollout excerpts can be provided if needed.