Background/Workflow agent no-progress watchdog detects stalls but has no recovery path (recurring, well-documented, keeps getting auto-closed without a fix)

Preflight Checklist

• [x] I have searched existing issues. Closest matches: #63698 (closed as stale 2026-07-02, "Workflow subagent: one stall is retried 6× at full token cost..."), #48501 → duplicate-closed to #37080, #50802 → duplicate-closed to #48501, #72492 → duplicate-closed to #69975. Filing separately because the underlying defect keeps outliving the specific threads that document it — see "Why file a new issue" below.
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code (2.1.202, upgraded same day specifically to check before filing).

What's Wrong?

The no-progress / stream watchdog for background and Workflow-tool agents correctly detects a stalled agent, but there is no recovery path — the agent is simply killed and reported as a terminal failure, discarding all in-progress work. Tonight: 10 concurrently-dispatched background/workflow agents, 6 failed within the same short window, all with the identical message:

Agent stalled: no progress for 600s (stream watchdog did not recover)

One agent in the same batch completed normally, ruling out a general host/compute problem. The pattern (several independent, unrelated task lanes dying at once, on an otherwise-healthy machine) is consistent with a correlated stream/connection-layer event — the kind of transient server-side drop documented in #66095, #67766, and #69415 — that each lane's watchdog detected correctly but from which none recovered. All 6 units had to be fully re-dispatched from scratch, at full token/wall-clock cost.

What Should Happen?

On stall/stream-drop detection, the harness should attempt to resume the interrupted turn from the last committed state before declaring a terminal failure — #72492 already laid out why this should be tractable: stall detection ships, and partial-state preservation ships (keepPartialMessageOnAbort), so the missing piece is specifically the auto-resume/retry step, not new machinery from scratch. At minimum, a distinct signal for "the connection dropped" vs. "the model is doing legitimately long work" would let Workflow-orchestrated runs retry the former without discarding real progress.

Why file a new issue instead of commenting on an old one

This defect class has an unusually long paper trail that keeps getting closed without a fix landing:

• #37080 → #48501 → #50802: duplicate-closed chain on the base "stream idle timeout, no retry" defect. #48501's own body: "a host session went silent for 8 hours after hitting this error."
• #63698: near-exact match to tonight (Workflow-orchestrated subagents, no-progress watchdog kill, zero recovery, "0 of 3 units completed, ~5.2h wall-clock, ~1.79M tokens, zero output") — closed as stale on 2026-07-02, four days before an independent fresh recurrence (this report). I commented there today with the recurrence and requested reopening.
• #26729 → #72492 → #69975: another duplicate chain; #69975 is open today only because a commenter explicitly pushed back on the auto-close bot to keep it alive.
• #68842 (open): the inverse-shaped sibling — sometimes no per-agent timeout fires at all, so a stalled agent hangs 15–50 min instead of failing fast. Related but distinct: that's a missing timeout; this is a timeout with no recovery.
• #74317 (open, filed yesterday, independently audited across 49 Agent-tool launches with a 9/49 reproduction rate): a related-but-different mechanism — subagents fabricating a "waiting on a background agent" stall when nothing was actually spawned. Worth a shared look, since it may be a different manifestation of the same underlying gap (an agent's own bookkeeping about background work getting out of sync with reality).

The GitHub auto-duplicate/auto-stale bot appears to be closing legitimate, reproducible reports of this class faster than fixes ship — several of the threads above were closed as duplicates of other threads that were themselves eventually closed without a shipped fix. The bug survives every closure. I'd ask that whoever triages this also take a look at whether the auto-close policy is doing more harm than good for this specific recurring class — a five-thread duplicate chain with zero shipped fixes across roughly two months is a signal on its own.

Steps to Reproduce

1. Dispatch several (6+) concurrent long-running background or Workflow-tool agents.
2. Wait for a transient stream/connection disruption to occur naturally (the failure in this report was not deliberately induced — it happened under normal multi-agent load).
3. Observe whether affected agents recover automatically or terminate with Agent stalled: no progress for 600s (stream watchdog did not recover), discarding their in-progress work.

Error Messages/Logs

Agent stalled: no progress for 600s (stream watchdog did not recover)

(repeated identically across all 6 failed agents in the same batch)

Environment

• Platform: Windows
• Claude Code version at time of incident: 2.1.198 (upgraded to 2.1.202 same day to rule out a version-specific cause; changelog for 2.1.199–2.1.202 reviewed and contains no entry claiming to fix this specific defect)