claude-code - 💡(How to fix) Fix Workflow run shows "Running 2032m" indefinitely after the agent has died; cannot be stopped via UI Stop button or TaskStop (Run ID / Task ID both unknown)

Environment

Environment

• Claude Code 2.0.76, Windows 10.0.26100.6584
• Model: Claude Opus 4.x (1M context)
• Feature: Workflow tool (multi-agent orchestration), background mode

Summary

A background Workflow sub-agent became stuck in a loop, consumed ~1.4M tokens over 1,445 tool calls, produced no result, and then the run effectively died — but the UI continued to display it as "Running task 2032m 35s" with a live-looking Stop button. The displayed elapsed time (2032 min ≈ 33.9 h) exactly matches how long ago the run last wrote anything, confirming the timer keeps counting on a dead run. Neither the UI Stop button nor the TaskStop tool can terminate or clear it.

Steps to reproduce

1. Invoke the Workflow tool with a multi-cluster script that fans out ~8 parallel implementation sub-agents (file-disjoint), each told to implement issues + run tests, in background mode.
2. One sub-agent (cluster label impl:spectrum-alarms, shown as impl:dsp) enters a long/looping trajectory (observed: 1,445 tool uses, 1.4M tokens).
3. The parent workflow reports completion / the run stops writing to its run directory.
4. Observe the workflow card in the UI.

Expected

• A workflow sub-agent that runs away (e.g. >N tool calls or >N tokens) should hit a guardrail and be terminated, or at least be stoppable by the user.
• When a run ends/dies, its UI card should reflect that (not show "Running … <ever-increasing time>").
• TaskStop (or some documented handle) should be able to terminate/clear a Workflow run.

Actual

• UI shows "Running task 2032m 35s — 1.4M Tokens — 1,445 Tool uses — impl:dsp" with a Stop button, >34 h after the run last did anything.
• Evidence of death: the run's transcript directory …/subagents/workflows/wf_1136da5e-a33/ had its last file write 34.0 h before observation (a second run wf_bcadcaf1-5a6 similarly idle 36.0 h). A live agent writes continuously; nothing had been written.
• TaskStop fails both ways:
  • TaskStop(task_id="wswz8evgt") → No task found with ID: wswz8evgt
  • TaskStop(task_id="wf_1136da5e-a33") (the Run ID) → No task found with ID: wf_1136da5e-a33
• TaskList → No tasks found (the workflow run is invisible to the task API).
• Net: the user has no working way to stop or dismiss the run from within the session; it just sits there looking live.

Impact

• Wasted tokens at scale: ~1.4M tokens on a single sub-agent that returned nothing (its work was redundant — committed independently meanwhile), plus a separate ~3.5M-token workflow. For a small team this is a material cost.
• No runaway guardrail surfaced to the user: 1,445 tool calls / 1.4M tokens ran without an automatic stop or a warning prompt.
• Misleading UI: "Running 2032m" implies ongoing (billable) work, causing alarm about live spend when in fact the run was long dead.

Suggested fixes

1. Runaway guardrail: auto-terminate a workflow sub-agent past a token/tool-call ceiling (and surface it), or make the Workflow budget cap enforce a hard stop by default.
2. Stoppable runs: make the UI Stop button and TaskStop accept a Workflow Run ID (e.g. wf_…) and actually terminate/clear it; expose the Run ID in TaskList.
3. Accurate card state: detect a run with no activity for >M minutes and mark it stalled/ended, not Running, and stop the elapsed-time counter.
4. Pre-flight cost signal: before a large fan-out (e.g. ≥10 sub-agents), show an estimated token magnitude + require confirmation.

Artifacts (available on request)

• Run IDs: wf_1136da5e-a33 (impl, 8 agents), wf_bcadcaf1-5a6 (audit, 20 agents).
• Transcript dirs under the session's subagents/workflows/ with timestamps proving the >34 h idle.