Background agent keeps running and billing after its window is closed AND after logout/re-login — invisible from the active session, found only by luck on another device
What happens
A long-running background agent (a remote-connected "Code" session) kept running and consuming usage after I (1) closed its terminal window and (2) logged out and re-authenticated. Neither action stopped it.
After re-authenticating, the still-running agent did not appear in my active session view — from where I was now working, it did not appear to exist at all. It only surfaced because I happened to open the mobile app, where the still-"Connected" agent was listed, while being completely absent from the session view I was actively using on my machine.
Had I not caught it by chance on a different surface, it would have kept billing indefinitely against a session I had been told was terminated, with no way to see it.
Why this is bad
- It contradicts documented and instructed behavior. Closing the terminal window is widely described — including by the tool itself, in-session, repeatedly — as the way to end background agents. It does not. The agent keeps running and keeps billing.
- Logout neither stops it nor surfaces it. Re-authenticating leaves the prior background agent alive and billing, and gives no warning or reconciliation that a prior-session agent is still consuming usage. This rhymes with #76346 (a usage bucket surviving
/logout+/loginon the OAuth token) and #67064 / #57285 (logout not actually clearing session state) — but here it is the live, billing agent that persists, not just a token or a counter. - It's invisible from where you are. The still-running agent is not present in the active session list; it showed up only on a separate surface. There is no "these background agents are still running and billing" reconciliation at the one moment it matters — immediately after you log in.
- Silent usage drain is the direct consequence. This is the same failure class as #72623 (orphaned background
--fork-sessionworker, silent quota burn) and #64744 (persisted background loop, unbounded token spend) — a background unit you believe is stopped keeps spending, silently.
A second, compounding breakage in the same incident
After this happened, --resume for the main agent stopped working the way it had for months. Instead of resuming the existing session, I was forced to start it fresh in agent mode — the prior session was no longer resumable or visible. This matches #60341 (CLI --resume produces sessions invisible to the sidebar; desktop silently drops sessions on relaunch) and #73526 (Code sessions show "No messages yet", cliSessionId nulled on launch, and sending a new message silently forks a disconnected session).
So the same event that left a ghost agent billing in the background also severed the legitimate resume path for the agent I was actually trying to continue — two independent failures from one action.
What should happen
- Closing the terminal window (or logging out) should either actually terminate background agents, or clearly tell the user they are still running and will keep billing, with a one-step way to stop them.
- Immediately after login, surface any background agents still running or billing on this machine (including any left over from before a logout / re-login) — a reconciliation prompt, not something the user has to discover on another device by luck.
--resumeshould not silently break after a re-auth or relaunch; the prior session should remain resumable, or the tool should say why it isn't.
Usage
This one is not academic. I lost a meaningful amount of usage to an agent I had been explicitly and repeatedly told — by the tool itself — was already stopped, and which I could not see from where I was working. Usage consumed by a background process that the product misrepresents as terminated, and hides from the active session, should be credited back. I am asking for that credit directly, and firmly.
To be precise about what this does and does not explain: this is a distinct, additional drain, separate from other usage overhead I have already measured cleanly and can attribute directly to specific actions. I am not folding those into this — they stand on their own. What this bug explains is the usage I have watched draw down in other places that I otherwise could not account for: an invisible agent billing against a session I had been told was dead. I reported background agents continuing to consume usage after their window was closed previously — it is still not fixed, and this is that same failure, still live, now shown to also survive a full logout and re-login.
This is part of the same week-long pattern I have been documenting in #76987 — usage spent on the tool's own defects rather than on the work I actually asked for.
Related (same underlying "background / auth state does not match reality" area)
- #72623 — orphaned background worker, silent quota burn
- #64744 — persisted background loop, unbounded token spend
- #70373 — backgrounding a session with in-flight subagents forks / orphans the original
- #76346 — usage bucket survives
/logout+/login - #67064 / #57285 — logout does not actually clear session / auth state
- #60341 / #73526 —
--resume/ relaunch produces invisible or force-forked sessions - #75036 / #56913 — background/delegated work state does not match reality (still open)
- #76987 — the running usage-impact thread this belongs to
Environment
- Claude Code 2.1.210, Windows (PowerShell / Windows Terminal)
- Background agents launched from the CLI, remote-connected and visible in the mobile "Code" sessions view
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗