Sub-agent API 401 (auth expired) is reported to parent agent as "Request interrupted by user for tool use"

This is a serious ergonomics problem in multi-agent workflows -- the parent agent losing diagnostic context on a 401 is worse than just a confusing message. It picks the wrong recovery strategy (asks the user "did you cancel?" when the real answer is "your token expired, run /login").

The error conflation is the most impactful part: auth_expired, rate_limited (429), and user_cancel are three completely different situations that all land as [Request interrupted by user for tool use] right now. Each needs a different recovery path.

Surfacing the apiErrorStatus to the parent would let orchestrators implement proper retry logic -- e.g. pause the fan-out, bubble a /login prompt to the top-level session, then resume. Without it, any multi-agent workflow that runs longer than a token TTL is fragile by design.

Update: same misclassification pattern observed in a different upstream cause — connection drops mid-response, not auth expiry.

In a long-running multi-agent session this week, the parent agent received [Request interrupted by user for tool use] on a sub-agent dispatch. The session JSONL transcript shows the actual upstream signal was NOT a 401:

{
  "type": "assistant",
  "model": "<synthetic>",
  "error": "server_error",
  "apiErrorStatus": null,
  "isApiErrorMessage": true,
  "content": [{
    "type": "text",
    "text": "API Error: Connection closed mid-response. The response above may be incomplete."
  }]
}

Two independent instances in one session (~6 hours apart). The 401 case (which this issue filed) was also present once in the same session — three <synthetic> events total: one authentication_failed/401 plus two server_error/null.

Both variants exhibit the same harness behaviour: a <synthetic> model message with isApiErrorMessage: true, bubbled to the parent agent as [Request interrupted by user for tool use] — so a fix targeting just the 401 case would leave the connection-closed case unaddressed.

Suggested scope expansion: any <synthetic> isApiErrorMessage event (regardless of error class — authentication_failed, server_error, future variants) should propagate to the parent with the original error class and status preserved, not collapsed into the user-interrupt class.

---
TL;DR — additive independent repro; please do NOT auto-close as duplicate. This
confirms and extends #70958; it is not a restatement of it, and it is distinct from
every near-neighbor:

• Not #69856 — that report's cause is pkill bun (an external process kill), and

it's misfiled under a model-behavior title. Ours involves no pkill; the trigger
is an upstream 401/429 returned to a subagent mid-tool-use.

• Not the #29238 → #21358 chain — that cluster was auto-deduped into "bash

commands timeout on linux," an unrelated bug, then locked. This is subagent API
failure → fake user-interrupt, with transcript evidence.

• Not the "task stuck in /workflows" reports (e.g. #65925) — those are UI/restart

state reconciliation. This is a different layer: the run genuinely dies because
agents never resolve and no terminal event is ever written.

New vs #70958 itself: (1) also fires on 429, not just 401; (2) hits
Workflow-tool subagents, not only Agent-tool ones; (3) the downstream effect
silently kills the entire workflow (journal frozen at started:N/result:M, task
stuck "running", nothing surfaced).
---

Independent repro of this on Workflow-tool subagents, with two additions: the
trigger isn't only 401, and there's a downstream consequence that silently kills
whole workflows.

Environment: Claude Code (macOS, Apple Silicon). Observed across two unrelated
projects ("Definitely-Not-Prod" and "Held-Together-With-Duct-Tape").

Same mechanism, wider trigger. Subagents spawned inside a Workflow-tool run hit
upstream API failures mid-tool-use — both 401 (auth expired) and 429 (rate
limit) — and the failure is reported to the parent as
[Request interrupted by user for tool use] / "The user doesn't want to proceed
with this tool use." No user acted. Raw signature counts in the affected agent
transcripts: run A = 27×401 / 6×429; run B = 49×401 / 67×429. Each dead agent's
final entry is a tool_use with stop_reason: tool_use, immediately followed by the
bogus user-interrupt marker. So the fix shouldn't be scoped to auth (401) alone — any
upstream subagent failure (429 included) is being laundered into a fake user
cancellation.

Downstream consequence (new): the whole workflow silently dies. A workflow run's
journal.jsonl is an append-only heartbeat — one line per agent start, one per agent
result. When subagents are killed by this mislabeled interrupt, they never emit a
result, so the journal is left at started:N / result:M (M<N) with no terminal
aborted/error event. Nothing surfaces this: /workflows shows nothing, no
notification fires, and the task stays "running" indefinitely. Of 14 terminal runs
sampled, 2 died exactly this way (~14%) — intermittent, and correlated with periods
of upstream 401/429.

How to detect it from disk (no special tooling — the journal is enough). Match
agents on their key field (a hash of prompt+opts, stable across resumes; raw
started/result counts are not, since the journal is cumulative across resumes). A key
with a started and no result, on a run whose journal has stopped being written,
is a dead agent:

import json, os, time

def classify(run_dir, stall=300):
journal = os.path.join(run_dir, "journal.jsonl") # .../subagents/workflows/wf_*/
started, resolved = {}, set()
for line in open(journal):
line = line.strip()
if not line:
continue
try:
ev = json.loads(line)
except json.JSONDecodeError:
continue
key = ev.get("key") # prompt+opts hash; resume-safe
if ev.get("type") == "started" and key:
started[key] = ev.get("agentId")
elif ev.get("type") == "result" and key:
resolved.add(key)

unresolved = [a for k, a in started.items() if k not in resolved]
idle = time.time() - os.path.getmtime(journal) # age of newest heartbeat
if idle < stall: # still writing → alive (maybe mid-think)
return "ALIVE", unresolved
return ("SILENT_DEATH" if unresolved else "COMPLETE"), unresolved

Pointed at an affected run dir, this returns SILENT_DEATH plus the agentIds that
started but never resolved — the same ones whose transcripts carry the false
"user rejected" marker.

Asks:

1. Don't launder upstream subagent failures (401 and 429, and presumably other

5xx/API errors) into [Request interrupted by user for tool use] — surface the
real status to the parent/workflow.

1. On any subagent/runtime teardown, write a terminal aborted/error event to

journal.jsonl instead of leaving started:N / result:M.

1. Surface a dead workflow to the main loop and /workflows rather than leaving the

task "running".

Related: #6836 (meta tool_use/tool_result mismatch), #69856 (same workflow-journal
silent-death signature, misfiled under a model-behavior title).

Thanks @kristoffersingleton-yale for the careful differentiation from the neighboring reports; that precision is what keeps this thread from being folded into the wrong cluster. Your trigger matches what we observe on our fleet: an upstream auth failure returned to a subagent mid-tool-use, no external process kill, surfaced to the parent as a user interrupt. Your 429 flavor landing in the same wrapper strengthens the case that this message is a catch-all for subagent API failures rather than anything user-initiated.