[Bug]: Session reaper counts host sleep as idle time, so sleeping over 30 min kills every provider session on resume

[supermicro-danem]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

ProviderSessionReaper measures session idleness in wall-clock time, so time the host spends suspended counts as idle time. Sleeping a laptop for longer than the inactivity threshold therefore reaps every live provider session on the first sweep after resume, even though the user's actual interaction gap was "closed the lid, opened the lid".

The server already has the signal needed to exclude suspended time. HostPowerMonitor carries a suspended flag in its HostPowerSnapshot, but the only consumer is BackgroundPolicy (BackgroundPolicy.ts:147). The reaper never consults it.

ProviderSessionReaper.ts:

const DEFAULT_INACTIVITY_THRESHOLD_MS = 30 * 60 * 1000;
const DEFAULT_SWEEP_INTERVAL_MS = 5 * 60 * 1000;
...
const now = yield* Clock.currentTimeMillis;
...
const lastSeenMs = Date.parse(binding.lastSeenAt);
if (now - lastSeenMs < inactivityThresholdMs) continue;
...
const lastActivityMs = Math.max(lastSeenMs, Date.parse(thread?.session?.updatedAt ?? binding.lastSeenAt));
const idleDurationMs = now - lastActivityMs;
if (idleDurationMs < inactivityThresholdMs) continue;
...
yield* providerService.stopSession({ threadId: binding.threadId })

Both inputs are persisted wall-clock timestamps compared against current wall-clock time. lastSeenAt is only refreshed by provider activity (lastSeenAt: now on directory.upsert), and nothing re-baselines it when the host wakes. A suspended process generates no activity, so the full sleep duration lands in idleDurationMs.

ProviderSessionReaperLive is wired with no option overrides (server.ts:445), so the 30-minute threshold and 5-minute sweep are what ships.

Steps to reproduce

1. Start a turn on a thread and let it settle, so the session is running with activeTurnId null and no background liveness.
2. Sleep or hibernate the host for more than 30 minutes.
3. Wake it.
4. Within one sweep interval, the session is stopped with reason: "inactivity_threshold", and provider.session.reaped is logged. The thread survives but has no bound provider session.

Expected behavior

Time the host spent suspended should not count toward the inactivity threshold. Either exclude suspended intervals from idleDurationMs, or re-baseline lastSeenAt / skip one sweep on resume, so that a sleep is not equivalent to the user walking away for the same duration.

Actual behavior

Every non-stopped session whose last activity predates the sleep by more than the threshold is reaped on resume. A laptop closed overnight therefore comes back with all of its provider sessions stopped.

Impact

Minor bug or occasional failure

Version or commit

main @ 9d4bb55. Symptom observed on desktop 0.0.40.

Environment

T3 Code desktop 0.0.40, Windows 11, provider Claude Code. Reported symptom that led here: after the host slept, pressing stop/close on a thread produced No active provider session is bound to this thread. (the failing stop path itself is #11796).

Logs or stack traces

provider.session.reaped
  threadId: <id>
  idleDurationMs: <at least the sleep duration>
  reason: "inactivity_threshold"

Workaround

Send a new message to the thread; the session resumes from resumeCursor. The reap is not data-destructive, it just unbinds the session.

The counter-argument, and why this still seems wrong

Reaping a session that has genuinely been idle for 30 minutes is the intended policy, and by wall-clock measurement a slept host qualifies. Two things make the suspended case different:

1. The rationale for reaping is resource reclamation, and a suspended provider process is already consuming nothing. Nothing is reclaimed by killing it at the moment the host wakes.
2. The threshold is calibrated against user inattention. Sleep is not inattention of the same kind: from the user's point of view they resumed immediately, and the sessions they left open are gone.

The reaper's two existing skip conditions show the same intent already applies elsewhere: it deliberately refuses to reap a thread mid-turn (skipped-active-turn) or with background work in flight (skipped-background-work), precisely because wall-clock idleness misrepresents those states too. Suspended time looks like a third case of the same kind.

What I verified and what I did not

Verified by reading main @ 9d4bb55: the thresholds and that no options override them, that both comparison inputs are persisted wall-clock timestamps, that lastSeenAt is only bumped by directory.upsert on provider activity, that nothing re-baselines it on resume, and that HostPowerMonitor.suspended has BackgroundPolicy as its only consumer.

Not verified: a captured reap-after-sleep log. The affected thread was on another machine, and on the machine I had access to the trace files contain only effect-span records with no log lines, so provider.session.reaped would not appear there even if it had fired. The sequence above is derived from the code, not from a captured instance. Happy to attach a log if you want it confirmed first.

Related

• [Bug]: Turn interrupt on a stopped session settles nothing, leaving a dangling active turn and a permanently failing stop #11796 - the stop failure that surfaces after a session is unbound. This issue is one trigger for reaching that state; that issue is about the stop path not settling afterwards.
• feat(server): add guarded idle session stops #11202 - guarded idle session stops, same subsystem.

[juliusmarminge]

Triage

Confirmed as a real idle-clock bug in ProviderSessionReaper. Sleeping the host for longer than the 30-minute inactivity threshold will reap every non-stopped, non-busy session on the first sweep after resume.

What the code does

ProviderSessionReaperLive ships with no option overrides (apps/server/src/server.ts), so the defaults apply: 30 minutes idle, sweep every 5 minutes. Idle time is

Clock.currentTimeMillis (wall clock) minus max(binding.lastSeenAt, thread.session.updatedAt).

lastSeenAt is only written on ProviderSessionDirectory.upsert (session start / sendTurn / stop / resume-cursor persist). Nothing re-baselines it on host wake. The existing skip conditions (stopped, in-flight activeTurnId, backgroundLiveness) do not cover suspend.

HostPowerMonitor already exposes HostPowerSnapshot.suspended from Electron suspend / resume (DesktopTelemetryPublisher). Today that flag only feeds BackgroundPolicy (pause background work) and native telemetry sample backoff. The reaper never consults it.

Still true on current main (dc0869b60); no reaper / power-monitor changes since the cited 9d4bb550.

Fix note

Checking hostPower.suspended inside sweep is not enough. The process is frozen during sleep, so sweeps do not run while the flag is true. On resume the desktop clears it, then the overdue sweep runs and sees a wall-clock gap that includes the whole sleep.

A correct fix needs one of:

• subscribe to a suspended: true → false transition and re-baseline lastSeenAt (or record lastResumeAt and exclude that interval)
• skip the first sweep after resume
• subtract a detected wall-clock jump vs monotonic elapsed time between sweeps (more robust if desktop telemetry is late, stale, or absent)

Related, not duplicates

• [Bug]: Turn interrupt on a stopped session settles nothing, leaving a dangling active turn and a permanently failing stop #11796 — stop path that fails after a session is already unbound. This issue is one way to get there; that issue is the missing settle.
• feat(server): add guarded idle session stops #11202 — opt-in guarded thread.session.stop for Codex auth rotation.
• fix(server): give completed turns a full session idle window #10689 (merged) — give completed turns a full idle window via session.updatedAt; still wall-clock.
• fix(server): stop the reaper from silently killing live background subagents #5677 (merged) — skip live background work.
• fix(server): refresh provider session lastSeenAt on turn and task activity #5524 (open) — refresh lastSeenAt on activity; does not exclude sleep.
• fix(server): keep Claude messaging sessions alive #9612 (open) / [Bug]: Thread shows as live after the idle reaper has stopped its Claude Code process #9586 — Claude-only keep-alive if listSessions still reports the process; not a general fix.

No open or merged PR excludes suspended time from the idle clock.

Severity

Minor / occasional. Not data-destructive — send a new message and the session resumes from resumeCursor. Overnight lid-close can still stop every live session at once.

A captured provider.session.reaped line would be useful extra evidence but is not required to proceed.

Next step

Keep open. Implement resume-aware idle accounting in ProviderSessionReaper (and add a sweep test that jumps wall clock while monotonic time does not).