[BUG] Workflow subagents interrupted at ~180s while a model request is still in flight; identical-key retries restart cold and never complete

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Related but not a duplicate: #85206 reports the same class of failure with a different trigger and a different proposed fix. Details in "Additional Information".

What's Wrong?

In a long-running Workflow (plan → execute → synthesize cycles over a documentation repo), workflow subagents are killed mid-flight by what appears to be a stall watchdog, then restarted from scratch under the same cache key. Nothing is surfaced to the parent session.

Observed in a single run (wf_284abab8-8b6, ~2h in, still running as I write):

• 29 subagents spawned, 14 returned no result.
• 10 transcripts end with [Request interrupted by user] — with no user action. No Esc, no interrupt, no input of any kind was sent to the session.
• Five distinct workflow keys were restarted, two of them unboundedly:
• one key started 7 times, 0 results, across ~70 minutes
• one key started 3 times, 0 results, still looping
• No API error of any kind appears in any of the 29 transcripts — no overload, no rate limit, no context-length error. The agents are simply interrupted.

The watchdog fires on an in-flight request, not on agent age or tool inactivity

This is the part that differs from #85206 and I think it matters for the fix.

Measuring the silence between an agent's last transcript event and its interrupt:

180s, 180s, 180s, 180s, 180s, 180s, 232s, 146s, 0s, 0s

Six of ten land at exactly 179.7–180.0 s. (The two 0s entries are attempts cancelled almost immediately after a successful tool result — those look like the loop abandoning the key, not the watchdog.)

But a >180 s silent gap is not by itself fatal. Agents that completed successfully in the same run had maximum silent gaps of:

308s, 306s, 248s, 184s, 173s, 160s, ...

So the 180 s clock is not "time since the agent last did something" — agents routinely go quiet for 3–5 minutes and come back. It behaves like a ceiling on a single model completion that is still in flight. A gap composed of several shorter requests (including an auto-compaction round trip) survives; one request that runs past ~180 s gets interrupted.

Consequence: the fix proposed in #85206 — "key the watchdog on time since last tool event" — would not help this case. By that measure these agents were silent. What is needed is for the watchdog to distinguish "no response yet from an open request" from "agent hung".

The retry is cold, and therefore deterministic

Each restart begins with an empty transcript. The successive attempts re-read the same files in the same order and die at the same point in the reading sequence — attempts 2, 4, and the downstream retry all stopped immediately after reading the same large reference document. The loop cannot converge; it re-purchases the identical recon every time and re-hits the identical long completion.

Attempt durations for the 7×-restarted key were not a steady cadence:

8m46s, 5m18s, 23m16s, 4m33s, 4m27s, 10s, ...

The 23-minute attempt is one that auto-compacted mid-run and kept going, which is further evidence the agents are alive and working, not hung.

It is not a context-window problem

Peak assembled context does not discriminate between survivors and casualties:

completed, peak ctx: 164K, 161K, 156K, 150K, 150K, 148K, ...
killed,    peak ctx: 163K, 162K, 162K, 161K, 159K, 159K, ...

The single highest-context agent in the run (164K) completed normally.

Cost

| | output tokens | cache reads |
|---|---|---|
| run so far | 566,151 | 53.8M |
| agents that returned nothing | 124,584 | 25.0M (46%) |

Nearly half the run's token consumption has produced no durable output, and the two looping keys have produced literally none — their target files do not exist on disk.

Live confirmation

While writing this up I checked the one in-flight agent: it had been silent 173 s at 156K context. I predicted it would be interrupted at ~180 s. It was, and a fresh attempt for the same key spawned 32 seconds later. The behavior is reproducible enough to forecast.

What Should Happen?

1. An in-flight model request should not be interrupted by a stall watchdog. Distinguish "request open, no tokens yet" from "agent hung". If a ceiling is needed, it should be well above observed completion latency, or configurable.
2. A retry should carry forward the predecessor's transcript or a summary. A cold restart against a deterministic failure point guarantees the loop never converges.
3. Surface kills to the parent session. Nothing was reported. The only way to discover this was reading journal.jsonl and per-agent transcripts after noticing token spend out of proportion to progress.
4. Cap identical-key restarts and fail the agent() call with a visible error rather than looping 7+ times.
5. If the injected message is a watchdog action, it should not read [Request interrupted by user] — no user interrupted anything, and that string sends you looking in the wrong place.

Error Messages/Logs

# journal.jsonl — one key, 7 starts, 0 results, 7 distinct agentIds
started key=v2:f704edc6… agentId=aee521a9c4ebfe77a   06:01:57
started key=v2:f704edc6… agentId=a7f1b4ad01970619a   06:10:43
started key=v2:f704edc6… agentId=ab281dae688ff69e2   06:16:01
started key=v2:f704edc6… agentId=a81c684c0ac125775   06:39:17
started key=v2:f704edc6… agentId=aef8ab4411ee88b86   06:43:50
started key=v2:f704edc6… agentId=a9023d7b8ea1e214e   06:48:17
started key=v2:f704edc6… agentId=a9a3ecf749489ca30   ~07:05
# (no `result` line for this key at any point)

# a second key, same pattern, still looping
started key=v2:ffd6f0c0… agentId=a0ad32876a797d05f   06:48:30
started key=v2:ffd6f0c0… agentId=aa94acf0719d08480   06:56:13
started key=v2:ffd6f0c0… agentId=a668d4f8fe02ebfd3   07:02:45

# tail of a killed agent's transcript — working normally, then interrupted
+0.5s  06:53:13  assistant : text
+0.4s  06:53:13  assistant : tool_use(Read)
+0.0s  06:53:13  user      : tool_result
+0.1s  06:53:13  assistant : tool_use(Read)
+0.0s  06:53:13  user      : tool_result
+180.0s 06:56:13 user      : text   ->  "[Request interrupted by user]"

# subagent metadata (note: no model override recorded)
{"agentType":"workflow-subagent","spawnDepth":1}

Steps to Reproduce

I do not have a minimal reproduction — it needs a long run to surface. The conditions that reliably produce it here:

1. Launch a Workflow with plan → execute → synthesize cycles; workers and synthesizers each read a large set of markdown documents and then write one large document.
2. Let subagent contexts grow to ~150–165K assembled tokens (roughly 40–60 file reads plus a 6–8K prompt).
3. Give at least one task that is substantially heavier than the others — in this run it was the foundation module's spec, which loads the widest set of reference documents and must emit a ~35KB document in one turn.
4. Watch ~/.claude/projects/<project>/<session>/subagents/workflows/<runId>/journal.jsonl. That task's key accumulates started lines with fresh agentIds and never a result.
5. grep "Request interrupted by user" across the per-agent .jsonl files, and diff each marker's timestamp against the preceding event's timestamp — the ~180 s constant shows up immediately.

The heavy task fails on every attempt; lighter tasks in the same wave succeed, and a task hit once often succeeds on its retry.

I still have the full run directory (journal + 29 agent transcripts) and can attach or extract anything specific that would help.

Claude Model

glm-5.3, served through a third-party endpoint configured for this session. Workflow subagents inherit it — their meta.json records no model override.

Stating this plainly up front: the slow completions themselves may well originate at that endpoint rather than in Claude Code. That is not what I am reporting. The defect I am reporting is the harness's response to a slow completion — interrupt an open request at ~180 s, restart with no memory, loop without bound, and tell the parent session nothing — and all four of those behaviors are model-independent. #85206 reports the same retry-loop and no-surfacing behavior on sonnet.

Is this a regression?

Unknown — this is the first workflow of this size and duration I have run.

Claude Code Version

2.1.240 for the run; 2.1.241 currently installed.

Platform

macOS

Operating System

macOS 26.5 (build 25F71), darwin 25.5.0, arm64

Terminal/Shell

zsh

Additional Information

Relationship to #85206. Same failure class — watchdog kills a live subagent, identical-key retry loop, transcript discarded, parent session never notified, large spend for zero progress. Two differences worth separating:

| | #85206 | this run |
|---|---|---|
| kill cadence | steady ~8–9 min, tracks agent age | ~180 s, tracks a single in-flight completion |
| attempt durations | uniform | 8m46s / 5m18s / 23m16s / 4m33s / 4m27s / 10s |
| proposed fix in #85206 | key watchdog on time since last tool event | would not fix this — these agents were silent by that measure |
| subagent model | sonnet | glm-5.3 (no override recorded) |

If maintainers prefer, this can be folded into #85206 as a comment — I filed separately because the trigger and therefore the fix differ, and because points 2–5 under "What Should Happen?" hold regardless of which trigger is addressed.

Workaround. The #85206 reporter's workaround applies: run the failing task as a plain background Agent, which has no watchdog, then relaunch the workflow (relaunch resumes from cached results). A second mitigation on the authoring side is to have heavy agents create their output file early and edit it in sections, so a kill leaves durable partial work — as it stands, an agent that writes its document in one final call loses everything.