[BUG][SDK] task-notification resumes a stopped turn with an already-aborted AbortController — every later tool_use is cancelled and reported as a user refusal

Thanks for the detailed report. I tried to reproduce this on the released 2.1.233 build (macOS) with a harness driving the CLI over the streaming JSON protocol: streaming input, a permission handler (--permission-prompt-tool stdio), acceptEdits, a Stop hook configured, and a turn that dispatches a background Agent and ends. The background agent's completion notification started a new turn ~30 ms after the previous result, and in that turn the tool call was executed normally: the permission handler was consulted, the tool ran, and the result was returned (no "The user doesn't want to take this action right now" cancellation). I couldn't get the cancelled-tool behavior you describe.

Each turn (including one started by a background-agent notification) gets its own fresh cancellation controller, so we need to find what is aborting the notification turn in your setup. Could you share:

• A minimal harness script that reproduces it (in particular: does your harness call query.interrupt(), send an interrupt control request, or close the input stream when it sees the result message?), and any PermissionRequest/Stop hooks configured.
• A log from running with --debug-file /tmp/claude-debug.txt covering the notification turn, plus claude doctor output and whether it still happens on 2.1.233.

Separately, we agree that a programmatic cancellation should be distinguishable from a user refusal. Today the SDK user message already carries tool_result_meta.non_execution_kind: "cancelled" so a harness can tell them apart; making the model-facing wording distinct is something we're considering.

🤖 Generated with Claude Code

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.

Investigation update: 56 controlled runs, no reproduction — and one wording match

Following up on my original report. I've spent a full day trying to reproduce this in a controlled harness so you'd have a minimal repro. I could not reproduce it — 56 runs, 0 poisonings — but the negative result is itself informative, and one detail did reproduce exactly. Everything below is measured, not inferred.

1. The vector is broader than Agent

The original report described a backgrounded Agent/Task dispatch. I hit the same failure again on 2026-08-17 with a Bash call using run_in_background: true — no subagent involved. Same signature: the tool call was denied 45 ms after the tool_use, toolDenialKind: "cancelled", wearing the "The user doesn't want to take this action right now" wording, in the turn opened by the user message that carried the completion notification as an attachment. So any background work item appears to be a vector, not subagent dispatch specifically.

2. Confirmed mechanics

Two premises of the original diagnosis are now measured rather than assumed:

• Background tasks do not survive the query that launched them. They are killed, and the SDK emits a status=stopped notification rather than leaving them orphaned and silent. (6/6 with a query split, against 2/2 status=completed controls where the query stayed open.)
• That notification crosses a session boundary. Closing query 1 without waiting, then resume-ing the same session_id in query 2, ,delivers the notification into query 2 — reliably, ~5-6 s after it opens.

3. The wording matches — but nothing gets cancelled

Driving the real CLI headlessly (claude -p for turn 1, then -p --resume for turn 2), turn 2 receives a system / task_notification event carrying:

"may have been running when the previous Claude Code process exited"

which is the wording from the live incident. But the first tool_use of turn 2 is unaffected — it succeeds, every time. The notification arrives as a typed system event, and a typed system event does not poison anything.

That is the crux: in the live incidents the notification is fused as an attachment onto a user turn. Neither driveable path produces that shape. It appears to be specific to the CLI's own interactive turn loop.

4. Variables tested (all negative)

| # | Variable | Grid | Result |
|---|---|---|---|
| E1 | Task duration, single query | 14 runs, 5 s / 60 s, Agent + Bash | clean |
| E2 | Query/session boundary (close() → resume) | 8 runs, split vs control | clean; premises confirmed |
| E3a | Gap tightness before turn 2's first tool call | 12 runs, gap 0 / 250 / 1000 ms | clean¹ |
| E3c | Real CLI headless path + graceful / SIGTERM exit | 8 runs | clean; wording match |
| E3d | SIGKILL mid-flight + 3 concurrent background jobs | 6 runs | clean² |

All runs on claude-haiku-4-5, 120 s timeout, harness and full artefacts available on request.

¹ Caveat: even at gap 0, the notification still lands 5-7 s after turn 2 opens — the "tight boundary" this experiment targeted was probably never actually achieved. Inconclusive rather than refuting.
² Caveat: SIGKILL at +15 s killed the process mid-flight, but a backgrounded Bash cell exits on its own at ~11 s, so SIGKILL never caught that cell mid-sleep. Partial coverage.

5. What would help

The remaining hypothesis is that the poisoning requires the notification to be reinjected as an attachment on a user turn, which only the interactive CLI turn loop does. Two questions I can't answer from the outside:

1. Where does the CLI fuse a pending task notification into the next user turn, and does that path differ from the system/task_notification event the headless path emits?
2. In the resumed turn, is signal.aborted checked before the permission handler is consulted? In the incidents, canUseTool is never entered — the denial is synthesised upstream of it, which is why it wears human-refusal wording that no human produced.

The user-visible bug is arguably that wording, independent of the race: an aborted controller reports itself as a user refusal, which sends every downstream integrator hunting for a permissions problem.
It cost me four months and three wrong root causes. A distinct toolDenialKind surfaced in the message text would have made this a one-day bug.

6. Workaround in place, for anyone hitting this

Deny background dispatch outright in the affected session (PreToolUse hook on Agent/Task unless run_in_background: false, plus Bash with run_in_background: true), and route long work to a separate process instead. Since that hook landed I haven't seen a recurrence.

Happy to run any specific instrumentation you'd like against the harness — including a build with extra logging around the notification reinjection path.