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

@kcarriedo — flagging you here since you've independently documented this exact coordination / lifecycle / state-machine failure class alongside me on #56913 and #54393, and this is a clean new instance of it.

Same shape you articulated there: a background unit's real state — here, an agent that is running and actively billing — diverges from every surface the user can actually see. Closed the window (which the tool itself tells users ends background agents): still running. Logged out and re-authenticated: still running, still billing, and now completely absent from the active session view. The only place it surfaced was a different device, by luck. The primitives leave lifecycle and reconciliation to userspace — except now there's a direct, unrecoverable usage cost attached, and no reconciliation surface at the one moment it matters (right after login).

For the record: this class keeps getting reported — #72623, #64744, #76346, #75036, #56913 — and remains unfixed. It is not an edge case; it silently drains paid usage against sessions the product actively tells you are dead. Filing it as its own issue (#77876) with the full cluster linked so it doesn't vanish as a comment on one of the neighbors. It needs actual triage and a fix, not another auto-dedupe-and-close.

The "invisible session billing after logout" failure mode is genuinely bad, and the "found it by chance on a different device" part is the scariest detail here -- that's not a recoverable pattern for most users.

The root problem seems to be that session lifecycle is tracked per-surface rather than per-account. The session is "alive" at the account layer but the active-session view only reflects what the current surface knows about, so closing a window or re-authenticating doesn't propagate a stop signal to the background agent process.

A few things worth noting for anyone hitting this now:

• If you can still reach the mobile app (or another surface where the session is visible), closing it from there does seem to stop it. Not a fix, but a recovery path if you catch it in time.
• The Anthropic usage dashboard at console.anthropic.com should show active token consumption in roughly real time. If you're running long-horizon background agents and want a smoke alarm, checking there after closing a session is worth the habit until this is resolved.
• For unattended/overnight runs specifically, structuring them with an explicit time budget in the system prompt ("stop and summarize after X hours regardless of task state") gives a backstop against runaway billing -- the agent terminates on its own rather than waiting for an external kill signal that may never arrive.

This deserves a clear fix at the session lifecycle layer: closing the window or session view from any authenticated surface should propagate a stop to the background agent, and the active-sessions list should be account-scoped, not surface-scoped. The current behavior is a billing trap.

Update — the same stuck session has a second, opposite failure mode: it timed out and then sat idle for hours doing nothing

Follow-up on this exact situation, because it turns out a stale-auth background session is unmanaged in both directions.

The original report here was: a background session left running on an authentication I'd already signed out of kept running and billing invisibly. That's one failure mode.

Here's the other one, from the same kind of stuck session, later the same day: it timed out and disconnected itself — and then, instead of erroring, attempting to reconnect, or notifying me in any way, it sat completely idle for the entire afternoon. This was my main workload session. It produced nothing for hours and I only found out by going and checking.

So the two failure modes are mirror images of each other, same root cause:

• Keeps running and billing forever, invisibly (the original report), or
• Times out, self-disconnects, and sits idle forever, invisibly (this one).

The common thread is that a background/remote session on stale authentication is decoupled from any lifecycle management at all. Nothing keeps it alive when you want it alive, nothing cleanly stops it when it should stop, and nothing tells you which of those two things is happening. You cannot tell a session that's silently burning usage from one that's silently doing nothing — both look identical from where you're sitting, which is "not in front of that window."

One honest note on evidence: I can confirm the billing half of this eventually stopped, but only because an unrelated full OS crash killed the process outright and nothing respawned it — i.e. the only thing that reliably ended the runaway session was the machine crashing. The idle-timeout half I'm reporting first-hand; a later restart overwrote the session's on-disk timestamps, so I can't pin the exact minute it went idle, only that it did and stayed that way for the afternoon.

And to be precise about the cost, because it's not what you'd assume: the idle period itself burned almost nothing — on the order of 1-2%, and even that I can't cleanly isolate because other sessions were running concurrently. The expensive part had already been spent. This was the same session that cost roughly 40% of a weekly allocation just to resume and hand off (the startup + handoff overhead I measured separately in #76987). So the failure didn't waste usage by idling — it wasted usage by making that ~40% setup pointless. The session was expensively prepared and then, silently, did nothing with it. That's the real cost of this failure mode: not the idle, but the wasted preparation to reach it.

Same area as #75036 and #56913 (background work state not matching reality) and part of the ongoing pattern in #76987.