Sign up
View stargazers13Sign up

[Bug]: Command approvals stay pending after a delegated task is cancelled#21935

opened4d agobyEeowca

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.

The effect on any UI view was not inspected.

JJulius Marminge4d ago

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.

Ppedrozimmermannsoares2d ago
Synced from GitHub

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).

JJulius Marminge1d ago

Verified the state regression on main snapshot 3b95e7831b: 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.