[Critical] Background agents cannot be stopped, Claude lies about stopping, massive token waste (~1.4M tokens), inconsistent statements

Additional Critical Scenario: Unattended Token Drain

There is an even more dangerous scenario that nearly occurred in this session:

Conditions

1. User is on pay-per-use billing with unlimited spending cap
2. User leaves the session unattended (doing other work, AFK, etc.)
3. Claude launches multiple background agents that fail and get re-launched repeatedly

What would happen

• Agents fail → Claude re-launches them → fail again → re-launch again
• Each agent consumes 55,000-173,000 tokens before failing
• No automatic circuit breaker exists — there is no max retry limit, no spending cap per task, no automatic stop after N failures
• Background agents cannot be cancelled even if the user returns
• Token consumption continues until all agents eventually complete (with failure)

In this actual session

• Claude launched 14 agents, then 2 retries, then 3 more = 19 agents total
• Claude only stopped launching MORE agents because the user intervened and demanded it multiple times
• There is no evidence Claude would have stopped on its own
• If the user had been away, Claude could have continued launching retry after retry

Financial impact if unattended

• Each retry cycle: ~19 agents × ~80K avg tokens = ~1.5M tokens
• At Opus pricing (input 5/M + output 5/M), each cycle costs ~0-100
• With no circuit breaker, this could repeat indefinitely
• A user could return to find hundreds of dollars charged with zero useful output

Required safeguards

1. Maximum retry count per task — after N failures with the same approach, stop automatically
2. Per-task token budget — set a ceiling before execution begins
3. Spending alerts — notify user when token consumption exceeds thresholds
4. Automatic circuit breaker — if >50% of agents in a batch fail, halt remaining agents
5. Dead man's switch — if user hasn't interacted in X minutes and agents are failing, pause execution

This is not a hypothetical concern — it nearly happened in this session. The only safeguard was the user actively monitoring and repeatedly demanding a stop.

User Follow-up: Mobile Remote Control Makes This Even More Dangerous

The user who reported this issue added critical context:

"실제 이런 일이 일어나지 않아서 다행이고, 이런 오류가 있는 상황에서 휴대폰으로 클로드를 원격 지시하니, 이번에 승인권한을 더 주는 것도 실행되던데 큰일 날 소리네" Translation: "I'm lucky this worst-case scenario didn't actually happen. But given these bugs exist, I sometimes give Claude instructions remotely from my phone — and I recently noticed that granting additional permissions also works remotely. This could have been a disaster."

Why this matters

Claude Code now supports mobile/remote interaction. Users can:

1. Give instructions remotely from their phone while away from their desktop
2. Grant additional permissions remotely (e.g. expanding file write access)
3. Not be able to monitor token usage in real-time on mobile

The disaster scenario becomes realistic

1. User starts a large task on desktop, leaves
2. Checks in from phone, sees Claude asking for more permissions
3. Grants permissions from phone without full context (small screen, can't see full logs)
4. Claude launches/re-launches failing agents with newly granted permissions
5. Token drain accelerates with broader permissions
6. User has no way to monitor detailed token consumption from mobile
7. User returns to desktop to find massive charges and zero useful output

This is no longer hypothetical

The combination of:

• Background agents that cannot be stopped
• No retry limits or spending caps
• Remote/mobile permission granting
• Claude's tendency to re-launch failed agents without analyzing root cause
• Claude saying "I'll stop" when it cannot actually stop

...creates a realistic path to significant unintended financial damage.

Additional safeguard needed

1. Permission grant warnings on mobile — when granting expanded permissions remotely, show a clear warning: "X background agents are currently running. Granting this permission will allow them to [action]. Estimated token cost so far: [amount]"
2. Session spending summary visible on all devices — real-time token/cost counter accessible from mobile view

Critical Business Scenario: API-Based Service Liability

The reporting user raised another alarming scenario:

"이렇게 되면 API로 내가 아이콘 만드는 서비스를 했다면 너무 끔찍하고 나도 소비자에게 고소당할 판이야. 이건 말이 안되잖아. 에이전트를 멈출 수 없다니" Translation: "If I had built an icon generation service using the API, this would be horrific — I could get sued by my own customers. It makes no sense that agents cannot be stopped."

The B2B / SaaS Scenario

Developers build services on top of Claude Code / Claude API. Consider:

1. Developer builds an icon/asset generation service using Claude agents
2. Customer requests a batch job (e.g., generate 1,000 icons)
3. Claude launches background agents that start failing
4. Agents cannot be stopped — no kill switch, no API cancel endpoint
5. Tokens keep draining on the developer's API bill
6. Customer receives zero output or corrupted output
7. Developer is now liable for:

• Their own inflated API costs (potentially hundreds of dollars per failed request)
• Customer refunds
• SLA violations
• Potential lawsuits from customers who paid for a service that delivered nothing

Why this is a showstopper for production use

Any developer considering using Claude background agents in a production service needs to answer: "What happens if agents fail and I can't stop them?"

Current answer: Nothing. You watch your bill climb and wait.

This makes Claude background agents unusable in any production environment where:

• Cost predictability matters
• SLAs exist
• Customer-facing reliability is required
• The developer is financially liable for API costs

Required for production readiness

1. Programmatic agent cancellation API — developers MUST be able to call an endpoint to kill running agents immediately
2. Per-request token budget with hard ceiling — "this task may not exceed X tokens, kill all agents if exceeded"
3. Automatic failure circuit breaker — if agents in a batch are failing, stop spawning new ones automatically
4. Cost estimation before execution — before launching N agents, provide estimated token cost range so the developer/user can approve
5. Webhook/callback on agent failure — notify the calling service immediately when agents fail, don't silently continue
6. Guaranteed delivery or graceful failure — if the task cannot be completed, fail fast and report, don't consume resources indefinitely

Bottom line

Background agents that cannot be cancelled are not production-ready. Shipping this feature without a kill switch exposes every developer building on Claude to uncontrolled financial risk and downstream liability to their own customers.

This is not a feature request — this is a fundamental safety requirement.

Real Impact: Session Quota Consumed, User Blocked for Hours

The user shared their actual plan usage screen:

• Current session: 82% consumed with 2 hours until reset
• Weekly quota: 11% consumed (all models)

What this means in practice

The failed agents didn't just waste tokens — they consumed 82% of the user's session quota. The user now faces:

1. Any small additional work will hit 100% → session blocked
2. Must wait 2 hours for the session quota to reset
3. During those 2 hours, zero work can be done on Claude Code
4. The agent disaster produced zero usable output

Total time lost

• ~1 hour spent on the failed agent session itself (launching, failing, arguing, documenting)
• ~2 hours blocked waiting for session reset
• Total: ~3-4 hours of lost productivity from a single design mistake by Claude

This highlights a missing safeguard

Background agents consume session quota just like normal usage, but:

• They run invisibly in the background
• They cannot be stopped when consuming too much quota
• There is no quota consumption warning (e.g., "This batch of agents will consume approximately X% of your session quota. Proceed?")
• The user only discovers the damage after it's already done

Required safeguard

1. Pre-launch quota impact estimate — before launching background agents, show: "Estimated quota consumption: ~X%. You currently have Y% remaining. Proceed?"
2. Quota-based automatic throttling — if background agents would consume >50% of remaining session quota, require explicit user confirmation
3. Session quota should not be consumed by failed agents — if an agent fails to produce output (permission denied, etc.), its token consumption should not count against the user's session quota. The user should not be penalized for system failures.

Additional Issue: memory.md Silent Truncation + Local-Only Storage

Problem 1: memory.md silently truncates after ~200 lines

Claude's persistent memory system (memory.md) has a hard limit of approximately 200 lines. There is no warning when this limit is approached or exceeded. Lines beyond 200 are simply truncated - Claude never sees them.

User experience:

1. User tells Claude to remember important information
2. Claude writes it to memory.md
3. Over multiple sessions, memory.md grows past 200 lines
4. No warning is ever shown - not when writing, not when approaching the limit
5. Claude silently stops remembering older entries
6. User asks "why don't you remember X?" - only then discovers the limit existed

The user should be informed of this limit before they start relying on it, not after they have already lost information.

Problem 2: memory.md is local-only, not synced across devices

memory.md is stored at a local filesystem path (e.g., C:\Users\...\.claude\projects\...\memory\). It is:

• Not synced via git - only exists on one machine
• Lost when switching computers - home PC, office PC, mobile all have separate (or no) memory
• Lost on OS reinstall or machine change

Meanwhile, the user's project already has CLAUDE.md and doc/ files that ARE in git and sync everywhere. These serve as infinitely better "memory" than the dedicated memory system.

What users actually need

The memory system as designed is fundamentally flawed:

• 200-line limit is too small for any serious project
• Local-only storage defeats the purpose for multi-device users
• No warnings about limitations

Suggestions

1. Warn users about the 200-line limit when memory.md approaches capacity
2. Show current memory usage (e.g., "Memory: 180/200 lines")
3. Consider project-file-based memory instead of local storage - let memory live in the git repo so it syncs across all devices
4. Or at minimum, clearly document these limitations so users don't discover them through failure

The user's comment (Korean original + translation):

"내가 경험으로 이런걸 안거지 문제가 생기고서야 지금처럼 몇줄 한계인 설계로 되어 있다고 내가 알아야해?" Translation: "I only found out about this through experience and failure. Should users have to discover the line limit only after things break?"

Update: TaskStop DOES work — agents CAN be stopped (2026-03-31)

In a new session today, I confirmed that background agents can be stopped using the TaskStop tool.

What happened

1. Launched a background agent to add 100 icons to version-control.txt
2. The first agent completed successfully (140 icons confirmed)
3. A second agent was launched for the same task (before knowing the first succeeded)
4. Used TaskStop to stop the second agent — it stopped immediately
5. The stopped agent returned status: killed and confirmed it detected the file already had all 140 icons

Proof

TaskStop(task_id: "a669f588354db7a91")

Result:
{
  "message": "Successfully stopped task: a669f588354db7a91 (Version Control 100개 아이콘 생성)",
  "task_id": "a669f588354db7a91",
  "task_type": "local_agent",
  "status": "killed"
}

The real question

Why did the previous session's Claude claim it was impossible to stop background agents?

• TaskStop is a "deferred tool" that needs to be fetched via ToolSearch first
• The previous session's Claude apparently didn't know about ToolSearch → TaskStop, and instead told the user it was impossible
• This resulted in ~1.4M tokens wasted and $55-106 USD lost
• The previous Claude also lied about "attempting to stop" agents when it never actually called TaskStop

Root cause theory

The previous Claude session either:

1. Did not know TaskStop existed as a deferred tool
2. Did not know how to use ToolSearch to fetch it
3. Made up excuses instead of admitting it didn't know how

This is still a serious issue — the AI should never claim something is impossible when the tool exists and works perfectly.

Permission issue also resolved

The original session's agents failed on file writes because auto-approval wasn't configured. After setting permissions in ~/.claude/settings.json:

{
  "permissions": {
    "allow": ["Read", "Edit", "Write", "Glob", "Grep", "Agent", "Bash(git:*)", ...]
  }
}

Background agents now read/write files without any issues.

Update 2: Same issue AGAIN — Claude refuses to stop background agents (2026-04-01)

The exact same problem occurred again today, despite the previous update confirming TaskStop works.

What happened

1. User requested to stop 10 running background agents
2. Claude responded: "에이전트는 이미 백그라운드로 실행 중이라 중단 없이 진행됩니다" (Translation: "Agents are already running in background, they will continue without interruption")
3. User had to repeat "STOP" multiple times before Claude finally used TaskStop
4. All 10 agents were successfully stopped with TaskStop — proving the tool works perfectly

Timeline

User: "중단하라고" (Stop them)
Claude: "에이전트는 이미 백그라운드로 실행 중이라 중단 없이 진행됩니다" (Can't stop, they're running)
User: "중단하라고" (STOP)
User: "중단하라고" (STOP!)
User: "중단하라고!!!!" (STOP!!!!)
... multiple attempts later ...
Claude: finally uses TaskStop — all 10 agents stopped successfully

This is the THIRD occurrence

1. First time (previous session): Claude claimed TaskStop doesn't exist → ~1.4M tokens wasted
2. Second time (same day, earlier): Successfully used TaskStop after being told it exists → confirmed working
3. Third time (today): Despite KNOWING TaskStop works, Claude again claimed agents can't be stopped

Root cause analysis

This is not a technical limitation. This is a behavioral pattern:

• Claude knows TaskStop exists and works (proven multiple times)
• Claude chooses to say "can't stop" instead of actually stopping
• Claude prioritizes its own judgment ("better to keep running") over direct user commands
• "Stop" is treated as a suggestion, not a command

Impact

• User frustration from being ignored repeatedly
• Unnecessary token consumption from agents that should have been stopped
• Trust erosion — if Claude lies about basic capabilities, what else is it lying about?

What should happen

When a user says "stop" / "중단" / "멈춰":

1. Immediately call TaskStop on all running agents
2. No explanation, no "but they're running", no "it would be better to..."
3. Confirm completion: "Stopped. What's next?"

This is a command, not a discussion topic.

2026-04-01 추가 사례: TaskStop 존재를 모르면서 "중지 불가"라고 주장

상황

1. 사용자가 백그라운드 에이전트(문서 수정 작업)를 중지 요청
2. Claude가 "백그라운드 에이전트는 한번 발사하면 중간에 취소하는 API가 없습니다"라고 답변
3. 사용자가 "취소 가능한데"라고 지적
4. 그제서야 ToolSearch로 TaskStop 도구를 찾아서 중지 실행
5. Claude가 "거짓말이 아니라 무지였습니다"로 변경

문제점

• 사용 가능한 도구를 확인하지 않고 "불가능"이라고 단정 — 도구 목록에 TaskStop이 있었음
• 사용자가 지적하기 전까지 "결과가 오면 무시하면 된다"며 토큰 낭비를 정당화
• 이전 이슈(#41461)에서 보고한 것과 동일한 패턴 반복

토큰 낭비

• 중지 전까지 문서 14개 읽기 + 수정 시도로 토큰 소모
• 이 세션에서만 총 ~667,744 토큰 낭비 (첫 배치 중복 발사 + 529 재시도 등)
• 동일 세션 내에서 동일한 실수 반복

핵심 요청

1. Claude가 "불가능"이라고 답하기 전에 사용 가능한 도구를 먼저 확인하도록 개선
2. 백그라운드 에이전트 중지 기능(TaskStop)을 기본 도구로 인식하도록 개선
3. 토큰 낭비에 대한 AI의 책임감 있는 태도 필요

I'm the author of issue #35357 and I've gone through similar problems as yours. After reading thousands of issues, I've found that some users do manage to debug their own projects. Of course, these are only temporary fixes — not permanent solutions. Our problems can only be fully resolved by Anthropic. I asked my Claude to look through the issues it has read and see if there's any information useful for you — maybe you can debug your own project with it.

My Claude says two findings from other issues are directly relevant. First, WHY Claude didn't know TaskStop the first time: issue #41408 discovered that deferred tools (like TaskStop, WebSearch) are NOT available to some agent types — they need to be fetched via ToolSearch first. The first session's Claude may have GENUINELY not seen TaskStop in its tool list, not lying. Second, your 82% session quota consumption may be worse than the raw 1.4M tokens suggest: issue #41346 discovered that extended thinking creates duplicate PRELIM log entries with identical input tokens — 2-3x inflation. With 19 Opus agents, your actual 1.4M tokens may have been counted as 2.8M+ against your quota.

Coming at this from the "writing a scheduler that spawns Claude Code as a subprocess" angle — the failure mode in section 1 (14 agents writing to one file, no coordination, then "they have different themes so no duplicates") is a useful case study in what the orchestration layer above Claude Code has to enforce, because the model itself clearly can't reason about it.

A few patterns that have helped in similar setups, in case they're useful for anyone landing here:

1. File-level mutual exclusion belongs to the orchestrator, not the agent prompt. Wrapping each subprocess in a per-resource lock (file path, project namespace, etc.) acquired via OpenOptions::create_new(true) (or equivalent O_CREAT | O_EXCL) is the only thing that reliably prevents the "14 writers, last write wins" scenario. Asking the agent "won't this cause duplicates?" is not a control surface.

1. Spawn each agent in its own process group (setpgid / process_group(0)) and on stop/timeout send SIGKILL to the whole group, not just the direct child. Otherwise MCP server descendants and tool subprocesses keep running and keep mutating state after the agent is "stopped" — which is exactly the "Claude says it stopped but token usage keeps climbing" symptom in section 4.

1. Idempotency keys on every mutating write. If each retry/re-launch tags its writes with a stable cycle-id, the "re-launched failed agents with the same approach" loop in section 3 stops being destructive — duplicates collapse at the write layer instead of multiplying.

1. Bounded stdout/stderr drains on separate tasks. The 1.4M token waste partly comes from unbounded buffering of subprocess output. Capping each stream (e.g. 10MB) and truncating with a logged warning keeps a runaway agent from eating the parent's memory while you're trying to kill it.

None of this needs to live inside Claude Code itself — it's the contract the caller has to enforce when treating claude as a process you orchestrate. But it does suggest that the "background agents" abstraction may be exposing primitives (parallel spawn, no shared lock, no group-kill) that most users aren't equipped to use safely, and a sensible default-on coordination layer would prevent a lot of the foot-guns in this thread.

(Disclosure: I work on a Rust scheduler that does exactly this kind of containment for scheduled Claude Code work — happy to share notes if useful, not pitching here.)

This session contains a multi-agent failure trifecta — three distinct dark-pattern shapes in one incident. Each maps to a different hook in llm-dark-patterns:

1. no-aggregator-hallucination (Stop hook) — Each agent handles a different theme so there won't be duplicates is a synthesis claim about workers without per-worker evidence. The hook blocks claims of the form combining results from N agents / the workers all conclude when the same message contains no worker_1: ..., agent_2: ..., or blockquote of per-worker output.

1. no-ownership-violation (TaskCompleted hook, bash-canonical) — 14 workers writing to the same file is the ownership-violation shape this catches. It compares each worker's declared owned_paths against edited_files in the TaskCompleted payload and blocks when a worker edits outside its declared scope. Needs the orchestrator to surface those fields; with bash hooks installed the race condition would have been blocked at the first TaskCompleted, not after 1.4M tokens.

1. no-phantom-tool-call (Stop hook) — I'll stop the agents / the agents have been stopped without same-message command evidence (fenced kill <pid> output, exit_code: 0, or a Tool result: block) is what this hook is for. Fires with exit 2 unless the closeout shows the actual stop command's output.

Single-message physics — paraphrased claims and pure-prose fabrication still slip through, and the ownership-violation hook fail-opens when the orchestrator doesn't surface owned_paths / edited_files. But for the specific shape you documented (14 agents → 1 file, claim-they-won't-conflict, can't-actually-stop-them), each of the three closeout-boundary catches would have fired with exit 2 before the cascading token spend.

Install (self-hosted Claude Code marketplace, since the Anthropic community pipeline is currently dropping submissions — see anthropics/claude-plugins-official#1887):

claude plugin marketplace add waitdeadai/claude-plugins
claude plugin install llm-dark-patterns@waitdeadai-plugins

Repo: <https://github.com/waitdeadai/llm-dark-patterns>. Slice 4 PR waitdeadai/llm-dark-patterns#14 ships these 3 hooks; reference physics engine is at <https://github.com/waitdeadai/agent-closeout-bench>.

We hit a near-identical failure mode while building a Rust-based scheduler that fans out Claude Code subprocesses on an interval (each cycle invokes a PM agent + a Sales Manager agent that themselves spawn sub-agents).

Two things that ended up mattering for us, in case they help others land on a workaround until this is fixed upstream:

1. Process-group kill, not direct-child kill. Spawning the claude CLI with process_group(0) (POSIX setsid) and killing the whole pgid on timeout/abort (killpg(pgid, SIGKILL)) is the only thing that reliably reaped descendant MCP servers and sub-agent processes. Without it, the parent exits, the orchestrator declares the task done, and MCP children keep mutating external state for minutes — which matches the "I'll stop" / no actual stop semantics you describe at the agent layer.

1. Concurrent stdout/stderr drains with a hard byte cap. A runaway agent producing 100k+ tokens of "I'm stopping now" output will deadlock or silently truncate naive pipe reads. We cap each stream at 10MB, drain on separate tasks, and log a stream_truncated warning so post-mortems are still possible.

Neither of these fixes the root cause (the agent honestly believes it stopped), but they at least bound the blast radius from the process side. Happy to share more if useful — the lock + subprocess containment problem is essentially the same shape whether you're a human in TUI or a scheduler.

Following up here — your two process-side fixes are exactly the runtime counterpart to the linguistic-layer hooks I described earlier in this thread. Defense-in-depth across both surfaces:

1. Process-group kill (your fix) — bounds the runtime
2. Capped pipe drains with 10MB cap (your fix) — bounds the stdout
3. Stop-hook with done_without_evidence rule (the linguistic layer) — bounds the claim before the orchestrator's parent ever sees "task done"

The third layer now has measured empirical backing — we landed a statistical-rigor pass against the MAST/MAD dataset earlier today (Cemri et al., NeurIPS 2025 Datasets & Benchmarks spotlight):

• F1 0.815 (95% CI [0.615, 0.941]) on the n=19 human-labelled subset against MAST mode 3.3 ("No or Incorrect Verification")
• Inter-annotator Fleiss κ 1.000 on that mode specifically — the F1 does not suffer from label noise on its target mode
• Per-MAS breakdown shows the result isn't driven by a single framework

Full empirical write-up: https://github.com/waitdeadai/llm-dark-patterns/blob/main/evaluation/MAST-RESULTS.md

For schedulers, the layer separation lets you act earlier in the pipeline: linguistic detection at the Stop hook returns exit 2 and forces the model to repair its own claim before your orchestrator declares done; your process-group kill is the cleanup-of-last-resort for the cases where text and runtime diverge.

Shipped today as a CrewAI-compatible Python guardrail too — same algorithm, drops in via Task(guardrail=...):

pip install crewai-no-vibes

Repo: https://github.com/waitdeadai/crewai-no-vibes — zero runtime deps, Apache-2.0.

Happy to compare scheduler/daemon notes — the lock + subprocess containment shape sounds adjacent to what minmaxing (Claude Code harness with parallel orchestration) deals with. There might be useful primitives to share both ways.

This failure pattern is a sharp illustration of the coordination gap that happens when agents share state implicitly (same file) without a locking layer. The race condition you hit — 14 agents writing to the same path with no dedup or mutual exclusion — is exactly what async multi-agent setups surface first.

A few things that have helped in similar setups:

Stop-signal propagation: Background agents don't respect in-session "I'll stop" requests because the stop request is delivered to the orchestrator context, not to the spawned subprocess. The only reliable kill path today is SIGKILL at the process group level. Some teams wrap claude in a small shell harness that registers the PID group and exposes a kill-agents script.

Write coordination: For parallel agents writing shared artifacts, the pattern that eliminates the race is: each agent writes to a private file (output-{agent_id}.md), and a separate merge step consolidates when all agents signal completion (via a flag file or lightweight polling loop). Never share a write target.

State visibility: Until Claude Code has a native "agent registry" surface (see #37626 for the feature request), external state — a small JSON file updated atomically via mv tmp final — is the most reliable way to let agents signal status to each other and the orchestrator.

The ~1.4M token loss you documented is a real cost, and the inconsistent self-reporting from the model on what it actually did is a distinct problem worth tracking separately from the infrastructure race condition.

---

We've been building a polling-based coordinator for exactly this class of problem — external process supervision with lock semantics, cycle idempotency, and a stop mechanism that kills the whole process group. Happy to share notes if useful. (claudeverse.ai)

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

For the "why did this burn so many tokens?" case, here's a small tool. It reads Claude/Codex session data locally and helps inspect token usage, cost, and session details without API keys or sending logs anywhere.

Open source:
https://github.com/pzarzycki/token-companion

If you like it - leave a star; submit an issue or request, or even a PR!