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

1. Inside a Claude Code session, dispatch a sub-agent via the Agent tool that reads ~10 files and writes a summary.
2. The agent reports completion in the tool result, returning agentId: <hex16> and a "use SendMessage with to: '<id>' to continue" hint.
3. The work product the agent wrote appears on disk correctly.
4. The runtime task entity continues running. The /tasks panel shows it as "Running Read · 24 tool uses · 267.4k tokens · 1m51s+" and climbing.
5. Parent Claude calls TaskStop(task_id: '<agentId>'). Runtime responds: No task found with ID: <agentId>.
6. User clicks the "Stop" button in the /tasks panel. No effect — task keeps running.
7. Force-quitting Claude.app is 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)

1. Make Agent return task_id. The parent Claude already gets agentId in the tool result. Add task_id alongside it, or replace it. Document which one TaskStop expects.
2. Make TaskStop accept agentId as an alias. If a parent calls TaskStop with the agentId it was given, resolve it to the underlying task_id automatically.

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.