10 background Agent tasks stuck running for 34+ hours, no way to cancel, burned ~1M tokens

This is the visibility and control gap in a nutshell: background agents run autonomously, which is the feature, but when they get stuck there is currently no recourse short of force-quitting the whole session.

A few things that have helped others in the same situation:

1. The ~/.claude/projects/<proj>/<session-id>/subagents/ directory contains one JSONL file per background agent. If the agent is genuinely looping, the last few entries will be repetitive tool calls. That can at least tell you what each stuck agent was doing when it went sideways.

1. From the CLI, pkill -f "claude.*--agent" will kill child Claude processes associated with background agents without nuking your main session on desktop. Not elegant, but it stops the bleeding.

1. The token cost for a hung background agent is real and there is no automatic circuit-breaker today. The only safeguard is the session limit, which you already hit.

The root issue is that background agents have no max-turn or max-token cap independent of the main session, and the task panel's cancel button does not propagate a kill signal to the subprocess. These are known gaps -- #22625 (per-subagent token tracking) and the agent hierarchy dashboard request (#24537) both touch this. Worth leaving a link to this report there.

If you are doing parallel research workloads with agents, one pattern that reduces this risk: use Workflow builder agents with explicit maxTurns per stage rather than open-ended background Agent tasks. The workflow runner does enforce stage timeouts. Cold comfort for the quota that's already gone, but worth the config overhead going forward.

I saw your issue about background agents getting stuck for 34+ hours and burning ~1.08M tokens with no output. That looks like a classic agent loop / cost-spike failure pattern.

I’m the solo founder of Rootlyze, a public-beta tool that turns failed AI-agent runs into diagnosis, evidence signals, prevention guidance, and proofpacks.

If you have a sanitized trace/log from one of those sessions, I can run it through Rootlyze and send back a short proofpack showing the likely failure family, evidence signals, and what to check next. No secrets needed.

Want me to try it on one trace?

yes. I dont know what that stuff is.. very basic developer here lol

On Wed, Jul 8, 2026 at 6:46 AM Bosco @.***> wrote:

hermes6941 left a comment (anthropics/claude-code#75314) <https://github.com/anthropics/claude-code/issues/75314#issuecomment-4913991700> I saw your issue about background agents getting stuck for 34+ hours and burning ~1.08M tokens with no output. That looks like a classic agent loop / cost-spike failure pattern. I’m the solo founder of Rootlyze, a public-beta tool that turns failed AI-agent runs into diagnosis, evidence signals, prevention guidance, and proofpacks. If you have a sanitized trace/log from one of those sessions, I can run it through Rootlyze and send back a short proofpack showing the likely failure family, evidence signals, and what to check next. No secrets needed. Want me to try it on one trace? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/75314?email_source=notifications&email_token=BPYKTZDCPWX3W2TCLIKWHLL5DYRBLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJRGM4TSMJXGAYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4913991700>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPYKTZBOVNN6IKYM2J6H2LT5DYRBLAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIOBTGAYTONZSGQZ2C5QC> . You are receiving this because you authored the thread.Message ID: @.***>

No worries — you don’t need to understand the category first.

Think of Rootlyze as a simple “scan my failed AI/dev run and tell me what went wrong” tool.

Easiest ways to try it:

1. Paste an error/log here
2. Upload or point me to one failed run file
3. If you have a project folder with logs, Rootlyze can scan the folder and look for likely failure signals

You don’t need to prepare anything fancy.

Just remove secrets/API keys/private data and send one thing that failed — terminal output, agent trace, error log, or a file/folder with the failure.

I can run it and show you the proofpack result: what failed, evidence, likely cause, what to try next, and what Rootlyze cannot safely conclude.

This matches a failure pattern I have seen across a few extended overnight runs.

The core problem: background agents have no heartbeat-to-cancel signal path. From the task panel UI, "cancel" is effectively advisory -- if the agent is mid-tool-call (especially a long WebSearch or subagent dispatch) it will not see the cancellation until the current tool returns. If the tool itself is stuck, the agent never gets the signal.

A few things that helped in my setup:

1. Set a hard per-session token budget via the usage_limit hook. When the hook fires, it writes a sentinel file and the agent checks for it at each PostToolUse. Not a clean kill but it stops the fan-out within one tool cycle.

1. Add a PreToolUse hook that checks wall-clock time since session start and refuses the Task tool if the session is older than your overnight window. Agents launched before midnight will not spawn more children at 6am.

1. For the stuck display problem: agent tasks that show "Running" after a process restart are often stale records in the workflows store. On macOS, you can check:

sqlite3 ~/Library/Application\ Support/Claude/claude_code.db "SELECT * FROM workflow_tasks WHERE status='running' ORDER BY created_at DESC LIMIT 20;"
Stale ones will have a start_time well before your last process restart. Safe to update to 'failed' manually.

The 1M token burn with zero output is the painful part. Until there is a server-side rate-limit-per-session (not per-day), this is a real risk with any long-running background orchestration.

Worth noting: if the tasks showed climbing token counts but no output, the agents were probably in a compaction/spawn loop -- they compact, lose context, re-read the task spec, decide to spawn sub-agents again, repeat. Bug 1 and Bug 12 in issue #54393 describe this exact pattern if you want the full breakdown.

The core issue here is the same as #68619 and #73829: the agent has no concept of "I'm not making progress." It keeps running identical operations for 34 hours because:

1. No completion gate — the agent finished its actual work but never received a terminal signal
2. No repeated-call detection — the same tool calls fire hundreds of times with no state change
3. No per-agent budget cap — 1.08M tokens burned because there's no hard ceiling

A PreToolUse hook solves all three:

• Completion gate: after the agent's last meaningful action, the hook verifies the work was terminal. If the next call is a duplicate of the previous one with no new arguments, it blocks.
• Repeated-call detection: hash the tool name + arguments. After N=3 identical calls with no state change between them, block the call. This would have stopped the 34-hour run after the first 3 repetitions.
• Budget cap: hard token ceiling per session. When the limit is hit, the hook blocks all further tool calls and forces the agent to summarize and exit.

ThumbGate implements all three as PreToolUse hooks. Free to try: npx thumbgate init

The principle: the agent should never be the one deciding when to stop. That decision belongs to a layer it can't override.

This is a painful bug - running 10 background agents for 34+ hours with no cancel path is a real problem, especially when it burns through weekly usage limits.

A few things that might help while Anthropic works on a fix:

From the terminal, you can try killing the daemon process directly:

pkill -f "claude daemon run"

Then restart Claude Code. The background agent state should reset.

If you want to prevent this from happening again, adding this to ~/.claude/settings.json disables the agent view entirely so background tasks cannot accumulate silently:

"disableAgentView": true

The root problem you're hitting - no visibility into which background sessions are actually running versus stuck, and no reliable cancel - is something a number of people are building tooling around. If you end up running multi-agent workflows regularly, it may be worth looking at tools that give you an external view of session state rather than relying on the built-in agent panel alone. Worktree-per-task isolation also helps limit blast radius when a session goes runaway.

Hope the token situation gets made right.

Same pattern I've seen when orchestrating multiple background sessions: the cancel/stop controls in the task panel update the UI state but don't propagate a real kill signal down to the Claude subprocess (or its process group). So the task shows as "stopping" or grey but the agent keeps running and consuming tokens underneath.

A few things that helped in similar setups:

1. If you're on a machine where you can run ps aux | grep claude, check whether Claude subprocesses are still alive. The task panel being unresponsive doesn't mean the process is dead.

1. Restarting the app clears the UI state but orphaned processes can keep running. A full killall node (or equivalent for your platform) after quitting the app is the nuclear option but actually stops the burn.

1. The underlying issue is that background agents run in their own process groups and the cancellation signal needs to kill the whole group, not just the tracked PID. This is a known gap -- several related issues (#45250, #41461, #58662) track this.

The 34-hour runtime with 1M tokens and no output is consistent with a stuck tool call that keeps retrying rather than the agent making progress. The verification tasks you described can get stuck if the agent can't reach a file or tool it expects.

Worth filing a billing support ticket -- Anthropic has credited users in confirmed stuck-agent cases.

This is a painful one -- 1M tokens burned with no usable output and no cancel path is a significant trust problem for anyone running agents in batch.

The core issue seems to be that the task panel controls do not actually cancel the underlying worker -- they may update UI state without sending a stop signal to the running agent process. Some questions that could help pinpoint:

• Were the tasks dispatched via the desktop GUI task panel or via claude --bg from the CLI?
• Did any of the 10 tasks produce any interim tool call output (visible in the task panel log), or were they completely silent for the 34 hours?
• After you force-quit Claude Code entirely and relaunched, did the tasks finally show as stopped, or did the daemon respawn them?

For the token waste angle: there may be an agent supervision gap where the task panel loses the handle to the running worker but the worker keeps executing against your quota. We ran into a similar pattern and ended up needing a kill at the process group level rather than through the UI.

Sharing this in case the token-waste detail is useful for the refund request -- the pattern (controls failing to propagate stop to the worker, tasks continuing to run and charge) seems like it should qualify.