Background agent sessions (claude --bg/claude agents): fast session termination, worker crash-loop on attach, and lost background-task completion records
Summary
Using Claude Code CLI in a workflow that dispatches multiple long-running sessions as background agents (claude --bg / /bg) and periodically reattaches via claude agents, we've observed three distinct problems, each on separate occasions (not simultaneously). Reporting them together since they all touch the background-session/agent lifecycle and may share a root cause — but this is an observation report, not a diagnosis. Happy to have maintainers deduplicate against existing issues.
Environment
- Claude Code version: 2.1.201 (native CLI install)
- OS: macOS, Apple Silicon (arm64)
- Usage pattern: multiple background agent sessions dispatched concurrently via
claude --bg//bg, some running tens of minutes to hours, periodically listed/reattached viaclaude agents
Observation 1 — Session terminates unexpectedly, often within ~10 minutes of last activity
A background session that was actively in use stops producing further output / is reported as no longer running noticeably sooner than expected — frequently within about 10 minutes of the last user interaction — with no indication the task had completed or that termination was requested. Observed across multiple distinct sessions.
Observation 2 — Worker crash-loop on attach
Attempting to reattach to a background agent session produced:
Attaching...
Sess<session-id> is currently running as a background agent (bg). Use `claude agents` to find and attach to it, or add --fork-session to branch off a copy.
[worker crashed (exit 1 — exit_with_message) — respawning...]The crash/respawn repeated and the session never became usable.
Observation 3 — Lost/orphaned background-task completion record on resume
On a separate occasion, resuming a session produced this message twice in the same resume:
No completion record was found for this background shell command from the previous session. It may have been stopped (via the UI, Monitor timeout, or agent teardown — these leave no transcript marker), or it may have been running when the previous Claude Code process exited. Check the output file for partial results before assuming it completed.No output/partial-result path was available to confirm the true final state of the affected tasks.
Pattern notes
- All three occur intermittently, not on every session.
- No single reliable local trigger identified (not obviously tied to sleep, network changes, or a specific command).
- Never observed all three in the same session at once.
Possibly related existing issues
Found via search, flagged for maintainer triage/dedup rather than asserted as the same bug:
- #72221 — background daemon supervisor "signal war" causing worker respawns
- #73332 — background agent workers reaped mid-work, never respawn through documented path
- #65216 — worker crash-loop on reopen from agents view
- #72171 — near-identical "no completion record" message, closed as duplicate of apparently-unrelated
/clear/plan-mode issues
Impact
Background agent sessions are core to this workflow (running multiple long-lived agents concurrently). These issues require frequent manual monitoring/recovery, and completion state for background tasks can't always be trusted after a crash/respawn or resume.
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Same problem and it's highly related with token usage.
As im Max user and these bug uses my 5 hour usage almost 20% at onec.
CLAUDE TEAM PLEASE FIX THIS BUG.
reference this git repo for fast fix : https://github.com/Rangizingo/cc-cache-fix
This is a thorough writeup of problems that are hard to reproduce in isolation but very common for anyone running agent fleets through the CLI. The three observations (early session termination, crash-loop on attach, lost completion records) are consistent with a shared root cause around the background session lifecycle not being durable across the client/host boundary.
On Observation 1 (early termination around 10 minutes): this pattern often correlates with the session hitting the idle-detection threshold rather than actual task completion. A workaround that has helped: have the background agent emit periodic heartbeat writes (even just appending a timestamp to a log file) to keep the session classified as "active" by the harness. Not a fix, but it keeps long-running agents alive longer while the upstream issue is addressed.
On Observation 2 (crash-loop on reattach): if the worker is crashing on attach from a second machine, checking whether the session's state directory is still intact helps isolate whether it is a file-lock issue vs. a protocol mismatch. The crash-on-second-attach pattern can sometimes be triggered by the first attach leaving a stale lock.
On Observation 3 (lost completion records): the completion record loss on crash/restart is the most painful of the three because it makes the agent fleet state unreliable on recovery. Until this is fixed, writing completion state to an external file (not just the session record) before the session exits is the most robust fallback - something like a
TASK_DONEmarker file that survives session crashes.The concurrency pattern you described (multiple --bg sessions, periodic reattach via
claude agents) is a legitimate production workflow and these bugs make it genuinely difficult to operate. Worth upvoting if you hit any of these.The crash-loop-on-attach symptom (worker crashed exit 1, respawning forever) is the worst of these three because it makes recovery impossible without killing the session entirely. You lose whatever state the agent had accumulated.
The 10-minute termination issue is probably related to the session monitor timing out background processes that produce no heartbeat output. Some people have worked around this by adding periodic progress writes to a shared log file inside the agent's task - not elegant but it keeps the process alive.
For the lost completion records: the "no completion record found" message means Claude Code exited before writing the transcript marker. Running a long agent fleet across a machine that might restart, sleep, or crash is effectively unsupported right now. The --bg flag helps but the durability guarantees are not there yet.
Are you managing these sessions with any external supervisor (launchd, systemd, a wrapper script)? Curious whether the crash-loop happens fresh on each attach or is triggered by the external process management.
Hitting this exact pattern with concurrent background agents on a longer-running orchestration setup. The combination of silent termination + crash-loop on reattach + no reliable completion record makes it very hard to trust background sessions for anything that runs more than a few minutes.
One thing that helped on our end: externalizing session state so the orchestrator can detect a stopped background agent and requeue the task rather than relying on the native completion record. Still a workaround though -- the root issue is that there is no stable handshake between the background worker and the session it was spawned from.
A few questions that might help triage:
claude agents attachpath, or doesclaude --resume <session-id>also trigger it?Flagging this for the Claudiverse beta -- we're working on a layer that gives background agents a persistent task state outside the session window, which is how we've been getting around the lost-record problem. Happy to share session logs if useful for triage.
Hitting the same three symptoms on an arm64 Mac (Claude Code 2.1.x). The crash-loop-on-attach is the most disruptive one for me - once a session enters that cycle there's no recovery short of killing the daemon and losing the in-flight work.
A few things that have reduced the frequency for me:
statusfield will tell you if the session recorded a clean exit or vanished mid-run. If it shows no completion record, treat the work as lost and re-dispatch.The MCP inheritance gap (issue #61053, closed as dup of #30280) makes this worse because sessions that need Slack or other integrations can't reliably be dispatched to background without losing those tools.
Would be useful to have a
claude agents --jsonfield that distinguishes "completed cleanly" from "disappeared" so tooling can differentiate the two. Right now both look the same from the outside.