Runaway Agent task burns tokens after completion; agentId ≠ task_id makes it unkillable from parent session
Summary
When an Agent sub-task wedges and continues consuming tokens after its completion message returns to the parent Claude, the parent has no working mechanism to kill it. The Agent tool returns an agentId (e.g. aad52fe8da19773e3), but TaskStop requires a task_id — these are different identifiers, and TaskStop with the agentId returns No task found with ID: <agentId>. The user's /tasks panel "Stop" button also fails to terminate the hung task. Only force-quitting Claude.app ends the leak.
Steps to reproduce
- Inside a Claude Code session, dispatch a sub-agent via the
Agenttool that reads ~10 files and writes a summary. - The agent reports completion in the tool result, returning
agentId: <hex16>and a "use SendMessage with to: '<id>' to continue" hint. - The work product the agent wrote appears on disk correctly.
- The runtime task entity continues running. The
/taskspanel shows it as "Running Read · 24 tool uses · 267.4k tokens · 1m51s+" and climbing. - Parent Claude calls
TaskStop(task_id: '<agentId>'). Runtime responds:No task found with ID: <agentId>. - User clicks the "Stop" button in the
/taskspanel. No effect — task keeps running. - Force-quitting
Claude.appis the only thing that terminates the task.
Observed cost
~270K tokens leaked after the agent's real work was complete. Material when it happens to a Pro-plan user.
Two suggested fixes (either works)
- Make
Agentreturntask_id. The parent Claude already getsagentIdin the tool result. Addtask_idalongside it, or replace it. Document which oneTaskStopexpects. - Make
TaskStopacceptagentIdas an alias. If a parent callsTaskStopwith theagentIdit was given, resolve it to the underlyingtask_idautomatically.
Secondary issue
The /tasks panel "Stop" button silently failed to terminate the hung task. Whatever runtime path it uses also needs to handle the wedged-task case. If Stop can't reach the task, the UI should at least surface that fact so the user knows force-quit is the next step.
Environment
- Claude Code: latest as of 2026-05-12
- Platform: macOS (Apple Silicon)
- Session: heavy multi-agent dispatch with multiple synthesizer-style sub-agents.
- Some MCP servers were disconnecting and reconnecting during the session — possibly relevant to the wedge state.
What we want as users
A guarantee that no runaway sub-agent can outlive the parent's intent to kill it. Right now the failure mode is: parent says stop, runtime ignores, user clicks stop, runtime ignores, only force-quit works — and the tokens that burn between "say stop" and "force quit" come out of the user's plan.
6 Comments
This looks like an ID/lifecycle contract problem more than a UI-only task bug. If the only identifier surfaced to the parent is
agentId, then every stop path needs to accept that id or expose the canonicaltask_idbeside it.A useful acceptance test would be: subagent returns a completed tool result and writes its artifact, then a fake hung runtime keeps reading files. From the parent and from
/tasks, stop must terminate the same underlying runtime, mark a final state (completed_but_stale/cancelled), and stop token accounting after that boundary.I’d also make
/tasksshow both ids plustokens_since_last_artifact. The scary part here is not just the wasted 270k tokens; it is that the parent has evidence the work is done but no durable kill handle for the thing still spending budget.Runaway subagents burning tokens after completion is brutal. Cozempic's guard daemon monitors the Claude process and applies graduated pruning at 4 context thresholds — it catches exactly this kind of silent token leak from agent tasks that should have stopped.
pip install cozempic— hooks wire automatically. https://github.com/Ruya-AI/cozempic — would be interested to hear if the guard catches these for you.270K tokens leaked after the agent finished — and no way to kill it because agentId and task_id are different identifiers. That is a real cost leak. Cozempic (https://github.com/Ruya-AI/cozempic) has a guard daemon that monitors context growth and auto-prunes at configurable thresholds, which helps cap runaway token accumulation. Its
zombie-teamsdoctor check also flags orphaned agent state in session JSONL.pipx install cozempic && cozempic guardto run it as a background watchdog.Runaway agents silently burning tokens is one of the worst failure modes. Cozempic's guard daemon monitors session size continuously and can prune aggressively when it detects runaway growth — it has 4 configurable thresholds that trigger increasingly aggressive strategies. The watchdog also monitors the Claude PID directly.
pip install cozempic && cozempic guard --session <id>to protect a specific session. Repo: https://github.com/Ruya-AI/cozempic — would love to know if it helps contain the leak.Closing — Anthropic team can reopen if useful. The substance is documented above.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.