[BUG] Desktop auto-archive kills ACTIVELY RUNNING sessions — in-flight background subagents terminated without warning or resume
Environment
- Claude Code 2.1.204, Claude Desktop app
- macOS 26.3 (build 25D125), Apple Silicon
Summary
When the desktop app auto-archives a session, it kills the session's running Claude Code process and every background subagent (Agent tool tasks) that process owns — even when the session is mid-task with live background work. There is no warning, no grace period, and killed background agents have no resume path: their in-process state is simply gone.
This is distinct from #58446 (sessions auto-archiving on a timer) and #59235 (request for an opt-out toggle): those describe when archive fires; this report is about what archive does to a live process. Even if the archive timing heuristics were perfect, archiving should never hard-kill active work.
Impact (one real day, 2026-07-07)
Running a multi-session parallel workflow (one orchestrating session + several worker sessions) on one project directory, we hit this ~8 times in a single day. Each occurrence terminated in-flight background Agent tasks:
- A long-running scoring agent, killed twice (once overnight after its watcher died, once mid-scoring)
- Two independent bug-fix agents, each killed mid-build before their first commit
- A database seeding agent and an eval-probe agent, killed mid-run
- The most recent occurrence killed a code-fix subagent that had produced analysis but committed nothing — total loss, full restart required
Repro (as best we can tell)
- macOS desktop app, a project with several concurrent sessions (some long-lived)
- Leave a session working — main loop active or background Agent tasks running
- Within roughly 30–90 minutes, the app auto-archives one of the sessions
- The archived session's process and all its child/background agents are SIGKILLed; background task notifications report the agent as stopped; no resume is offered
We have not found a reliable trigger; it correlates with having many sessions open on one project directory (similar bucket-scoped observation to #58446).
Expected
- A session with a running process or live background tasks is never eligible for auto-archive; or
- Archive of an active session requires explicit confirmation; or at minimum
- Archive gracefully drains: background agents get a checkpoint/park signal and a resume path instead of a hard kill
Workaround we adopted (works, but costly)
Standing instruction in every background-agent prompt: "commit+push after every green phase — host restarts kill in-process state." That caps the blast radius at one phase of work, but burns tokens re-establishing context on every relaunch and shouldn't be necessary.
🤖 Filed with Claude Code on behalf of the user
3 Comments
@digitalgrove-bit Long-running agents really benefit from lifecycle events being observable. Recording state transitions like spawned → paused → archived → resumed makes unexpected termination much easier to diagnose than simply seeing the final failure.
This failure mode is worse than an ordinary crash because you have no warning and no resume path -- the background agents are just gone, mid-task.
A few things worth noting for the investigation:
The core issue is that "archive" and "terminate" are the same operation at the process level. Archive probably needs a two-phase behavior: snapshot the session state first, then terminate. Right now it appears to skip the snapshot entirely when the heuristic fires.
For multi-session workflows specifically, the compounding effect is significant. If you have an orchestrating session + 6 worker sessions and auto-archive fires on the orchestrator, the workers are orphaned with no parent to deliver results to. They may run to completion but the output goes nowhere. The 8x/day you saw suggests the heuristic is tuned for single-session interactive use, not background orchestration.
Two workarounds that have helped until this is fixed:
run_in_background: trueon all Agent calls and write intermediate results to a state file on disk. Agents writing to disk survive the parent being archived -- you can reconstruct from the file even if the session is gone.Neither is a real fix. The right answer is archive-aware lifecycle events that agents can observe and respond to before the process is killed.
Live, first-hand reproduction just occurred (2026-07-17, 09:47 CEST).
While actively mid-conversation in a Claude Code session (desktop, claude.ai/code, Code tab session list), I captured a screenshot showing my own currently-in-use session displayed greyed out with an archive-box icon in the session list — while I was still typing in and receiving responses from that exact session, no idle period, no user action to archive it.
Within the ~30 seconds it took to take the screenshot, a third session in the list underwent the same transition: it appeared black/normal at first, then shortly after also flipped to the greyed-out archived-icon state — all while sessions remained active and in use.
This matches the behavior described in this issue: sessions being marked archived in the UI while still actively running, with no user action triggering it. Filing this as corroborating live evidence, not a new report.