Skip to content

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

Open

Description

@eowca

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.

Activity

  1. juliusmarminge commented on Oct 19, 2026

    @juliusmarminge
    Member

    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.

  2. added
    acceptedfeature request accepted
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 19, 2026
  3. pedrozimmermannsoares commented on Oct 21, 2026

    @pedrozimmermannsoares

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

  4. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions