Exact string "[Request interrupted by user for tool use]" returned on a FOREGROUND Task/subagent dispatch with no user interrupt (CLI, macOS, v2.1.212)
Preflight
Searched existing issues. This is related to but distinct from three open reports, and I've cross-linked them below rather than assume it's the same bug:
- #78255 — queued input consumed mid-turn as a phantom instruction the assistant executes (VSCode, 2.1.205). Different observable: that fabricates and runs an instruction; this one cancels a tool call with the user-interrupt string.
- #78151 — interrupting a turn silently kills background subagents, no string surfaced. This report is a foreground dispatch where the string is surfaced, with no preceding turn interrupt.
- #78559 — "tool-use calls occasionally rejected without user intent" during long sessions. Closest sibling, but that report is Windows, framed as an approval-flow rejection, and does not capture the exact string or isolate the subagent-dispatch trigger.
If maintainers determine this shares a root cause with any of the above, happy to have it merged/closed as a duplicate — filing separately because the observable, environment, and trigger are distinct enough to add signal.
Environment
- Claude Code version: 2.1.212 (confirmed via
claude --version) - Entrypoint: CLI (not VSCode)
- Platform: macOS (Darwin)
- Session: long-running interactive session (multiple hours, many dozens of tool calls — heavy use of the
Agent/Task tool to dispatch subagents)
What's wrong
On a foreground subagent dispatch via the Agent/Task tool (run_in_background: false) with a large prompt (~3–4k tokens), the tool call returned exactly:
[Request interrupted by user for tool use](surfaced to the model wrapped as <error>[Request interrupted by user for tool use]</error>).
The human operator did not press ESC, did not press Ctrl-C, and did not type or send any message before this appeared. The dispatched subagent never ran — no work was performed, the turn just terminated with the interrupt string. On the second occurrence, the operator's next action was to type a brand-new, unrelated message after the interrupt string had already appeared — i.e. the interrupt preceded any user input.
Occurred twice in one continuous session, both times on foreground Agent/Task dispatches with large prompts. Both were recoverable by simply re-issuing the dispatch.
What should happen
Per the documented behavior, [Request interrupted by user for tool use] should appear only when the user deliberately interrupts (ESC / Ctrl-C / sending a new message that cancels the turn). It should not appear on a foreground tool dispatch when the user has taken no action.
Steps to reproduce
Not deterministic, but the pattern across both occurrences was consistent:
- Long interactive CLI session (macOS), many prior tool calls.
- Dispatch a foreground subagent via the
Agent/Task tool with a large prompt (~3–4k tokens). - Occasionally the call returns
[Request interrupted by user for tool use]with no user interrupt; the subagent does not run. - Re-dispatching the identical call succeeds.
Impact
Non-fatal and recoverable (re-dispatch works), but in an autonomous/orchestration workflow it (a) misattributes a harness-side cancellation to a user action the user never took, and (b) silently drops the dispatched subagent's work until the caller notices and retries. Misattribution is the more insidious part: an orchestrator reasonably trusts "interrupted by user" as ground truth about operator intent.
Diagnostic notes / gaps
- Could not attach the session
.jsonlparent-chain (not available to me at report time); if a maintainer wants it, I can try to capture the transcript around a future occurrence. - No scheduled/cron task was active (verified) and no background tasks were colliding at the time.
- Frequency: 2 occurrences in ~1 long session; both on the foreground large-prompt Task-dispatch pattern above.
3 Comments
Third occurrence, same session — corroborating data point.
Since filing, this recurred a third time under the identical pattern: a foreground
Agent/Task subagent dispatch (run_in_background: false) with a large prompt (~2–3k tokens) returned exactly[Request interrupted by user for tool use]with no user action (no ESC/Ctrl-C, no typed message — the operator confirmed in real time they did nothing).Updated frequency: 3 occurrences in one continuous CLI session (macOS, v2.1.212), every one on the same trigger shape — foreground Task/subagent dispatch with a large prompt. Re-dispatching the identical call succeeds each time; the subagent never ran on the interrupted attempt.
Additional signal narrowing the trigger:
This further distinguishes it from #78151 (background-subagent kill, no string surfaced) and points at the foreground Task-dispatch path specifically. Still possibly a shared root cause with #78255's message-queue-mid-turn subsystem, but the trigger here is the dispatch itself, not observable queued input.
Additional occurrences from a second fleet, plus one correlation that may re-scope part of this.
Method: scanned 10,160 session transcripts for the exact string, then kept only
Agent-tool dispatches. The tool is namedAgentin these transcripts, notTask. 193 total matches, most of them ordinary human escapes on Bash, Read and WebFetch calls. After filtering, 43 dispatch occurrences.run_in_backgroundfalse or absent.40 of the 43 are on versions other than 2.1.212, so this is not new in 2.1.212 and goes back at least to 2.1.190.
Prompt size does not survive the larger sample. I estimated prompt tokens for all 10,030 Agent dispatches in the corpus. Interrupted ones run 70 to 9,049 tokens, median 1,114, against a median of 739 across all dispatches. Only 4 of 43 exceed 2,000. The "large prompt, 3 to 4k tokens" reading in my original report came from 3 events and does not hold at this sample size.
New signal worth checking. 5 of the 43 share a timestamp to within 0.2 seconds with an
API Error: Response stalled mid-streamin the same session (2026-06-30, 07-16, 07-17, and two on 07-18). That points at a path where a mid-stream stall reaches the parent as a user-interrupt string. If so, some share of this report is a mislabeling of #74514's stall rather than a separate cancellation, which would also explain why re-dispatch always works. The other 38 have no nearby API error, so it does not account for all of them.Additional occurrence + a diagnostic correlation that may help isolate the dispatch-time variant.
Occurrence (2026-08-05T15:41:52Z, Claude Code 2.1.206, macOS desktop app): a foreground
Agent/Task dispatch (run_in_background: false,model: sonnet, prompt ~1.5k tokens) returned exactly<error>[Request interrupted by user for tool use]</error>immediately at dispatch. The subagent never ran — no subagent transcript file was created. The operator was driving the session remotely from the iOS app and physically away from the Mac, so a keyboard ESC/Ctrl-C is ruled out, and no message was sent before the string appeared (the operator's next message, hours later, explicitly stated they had not interrupted). Re-issuing the byte-identical dispatch ~8 h later succeeded on the first try.Correlation seen on earlier occurrences in the same project (2026-08-02, 2026-08-04): dispatch-time phantom interrupts coincided with windows in which plain
Bashtool calls failed with:i.e. the auto-mode safety classifier's model being unavailable (cf. #39259). During those windows,
Agentdispatches died with the user-interrupt string; once the classifier recovered, Bash calls went through — though on 2026-08-04 the Agent dispatches kept phantom-failing for a while even after Bash recovered. This suggests the dispatch-time variant is an internal abort in the permission/classifier path being routed through the same reporting path as a user interrupt, consistent with your "cancels with the user-interrupt string" framing rather than the approval-flow-rejection framing of #78559.The mid-run sibling (subagent runs normally for tens of minutes, then dies with the same string exactly ~600 s after its last record — a watchdog on a stalled model request) has a distinct trigger and machine-measurable signature, so I filed it separately as #84346 with 13 transcript measurements.