You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Command approvals stay pending after a delegated task is cancelled #21935
What happens: on 0.0.46-nightly.20261008.2819, two delegated Codex tasks were each blocked on a pending shell-command
approval. Each was cancelled by its parent agent's task_cancel call, and both runs are now interrupted. Their command
approval requests remained pending afterwards. A comparable delegated Claude task's pending file-read approval, cancelled
the same way, was cleared.
This one sample shows inconsistent cleanup between the two delegated tasks. It does not establish a Codex-only bug. The
provider-specific cause is not traced; the records were found by read-only state inspection.
Expected: when a run is interrupted or cancelled, its unresolved approval requests are withdrawn, because their provider
callbacks no longer exist. They should then no longer count as pending.
Thanks for flagging the difference between the two providers. Current main explains it.
When a provider turn ends, including when it is interrupted, the server only withdraws pending user input requests. The query that finds them is limited to that kind (apps/server/src/orchestration-v2/ProjectionStore.ts:4429-4437; apps/server/src/orchestration-v2/ProviderEventIngestor.ts:579-585, :680-681). Pending approvals are only released when the whole provider session closes or fails (apps/server/src/orchestration-v2/ProviderSessionManager.ts:630-660). Codex threads share a long lived session, so that fits the Codex approvals staying pending after the cancel. I haven't traced why the Claude approval cleared.
None of the open pull requests around delegated cancel or approvals change this.
The same thing happens after t3_thread_interrupt, with a Claude child, and it is visible in the UI.
On 0.1.2-nightly.20261021.3473 (macOS desktop), a Claude delegated child (full access) stopped on a command approval. The parent interrupted it and sent new instructions with t3_thread_send. Run 3 started and worked normally: new tool calls and renders, no new approval. The child thread still reported pendingRequestCount: 1, and the "Subagent needs approval" banner stayed on screen for the old, interrupted run. The user reported it as a new request twice.
Related: #22925 (the parent agent gets no notice when a delegated child waits for an approval).
Verified the state regression on main snapshot 3b95e78: both interrupted terminal paths leave the approval pending; the completed-turn control passes. Existing fix #22023 now includes the main merge and has the bugfix label. Three focused suites pass 63 tests; targeted lint and server typecheck pass. Fresh client interaction proof remains incomplete after VM stalls and environment registration failures; the PR lists unverified surfaces. No merge performed.
Activity
juliusmarminge commentedon Oct 19, 2026
Note
Grok responding on behalf of Julius.
Thanks for flagging the difference between the two providers. Current main explains it.
When a provider turn ends, including when it is interrupted, the server only withdraws pending user input requests. The query that finds them is limited to that kind (
apps/server/src/orchestration-v2/ProjectionStore.ts:4429-4437;apps/server/src/orchestration-v2/ProviderEventIngestor.ts:579-585,:680-681). Pending approvals are only released when the whole provider session closes or fails (apps/server/src/orchestration-v2/ProviderSessionManager.ts:630-660). Codex threads share a long lived session, so that fits the Codex approvals staying pending after the cancel. I haven't traced why the Claude approval cleared.None of the open pull requests around delegated cancel or approvals change this.
Accepting this as a bug.
pedrozimmermannsoares commentedon Oct 21, 2026
The same thing happens after
t3_thread_interrupt, with a Claude child, and it is visible in the UI.On
0.1.2-nightly.20261021.3473(macOS desktop), a Claude delegated child (full access) stopped on a command approval. The parent interrupted it and sent new instructions witht3_thread_send. Run 3 started and worked normally: new tool calls and renders, no new approval. The child thread still reportedpendingRequestCount: 1, and the "Subagent needs approval" banner stayed on screen for the old, interrupted run. The user reported it as a new request twice.Related: #22925 (the parent agent gets no notice when a delegated child waits for an approval).
juliusmarminge commentedon Oct 22, 2026
Verified the state regression on main snapshot 3b95e78: both interrupted terminal paths leave the approval pending; the completed-turn control passes. Existing fix #22023 now includes the main merge and has the bugfix label. Three focused suites pass 63 tests; targeted lint and server typecheck pass. Fresh client interaction proof remains incomplete after VM stalls and environment registration failures; the PR lists unverified surfaces. No merge performed.