feat(chat): hibernate idle sessions when their view closes - #6087

🏆 Review leaderboard

Sep 23–30, 2026 · UTC

Rank	Reviewer	PRs reviewed	Review rounds	PR comments
🥇	@nikhilachale	28	57	8
🥈	@illegalcall	24	47	6
🥉	@ronishrohan	23	33	9
4	@Prasad-D-Ware	15	27	3
5	@codebanditssss	13	21	1
6	@Rishet11	10	19	10
7	@mohakchakraborty2004	8	8	5
8	@Annieeeee11	7	15	5
9	@neversettle17-101	6	8	5
10	@harshitsinghbhandari	5	7	0

Ranked by distinct external PRs reviewed, then review rounds, then PR comments. Self-activity and bot activity are excluded.

Show 9 more reviewers

Rank	Reviewer	PRs reviewed	Review rounds	PR comments
11	@Vaibhaav-Tiwari	5	5	2
12	@Pritom14	2	2	2
13	@Pulkit7070	2	2	1
14	@somewherelostt	1	3	2
15	@ApexYash11	1	2	2
16	@AgentWrapper	1	1	0
17	@aprv10	1	1	0
18	@Ayash-Bera	1	1	0
19	@LaibaFirdouse	1	1	0

Full macOS dev-build demo (Developer Mode ON): Claude ACP (0:00) and Codex app-server (1:45) each show a fresh session, first reply, hibernation with host/provider PID exit, reopen and second reply, then PID exit again. The two continuous provider takes are joined; sending before wake completes is not covered.

One lifecycle edge looks worth covering before merge: the view lease is only 30s, the daemon sweep is also 30s, and the renderer renewal is a chained window.setInterval(..., 10_000) in SessionView.

AO does not set Electron backgroundThrottling: false. Chromium background pages can substantially throttle timer wakeups, so a Chat view that is still mounted/selected can miss the 30s lease merely because the AO window is minimized/backgrounded.

That permits:

1. Chat stays open; no React cleanup sends active:false.
2. renderer renewal is delayed past chatViewLease.
3. HibernateIdleChats expires the still-real view and hibernates the provider.
4. the later heartbeat/foreground wake registers the same view again and resumes the provider.

So “view closed” can become “browser timer was suspended,” causing provider-process churn/native resume while the user never actually left Chat.

I would avoid solving this by globally disabling Chromium throttling. A stronger contract would make view ownership come from a non-throttled Electron/main lifecycle signal, or otherwise make crash-expiry distinguishable from normal background throttling. At minimum the lease should tolerate the browser’s worst-case renewal cadence.

A regression with the Chat component still mounted, renewal paused for >30s, and the hibernation sweep running would make this boundary explicit.

Checked against head 19cca8b5ffa92543f6157b2a72e9144195b79f08.

Hibernation came up as Dhruv Sharma's committed next work on the Oct 2 call: "as you move out of a session, if the session is idle, it will hibernate. Once you come back to your session, before even you start typing, you just click on the session, then the session wakes up" (30:36).

prateek flagged the risk this PR should design against: "we show an agent to be idle even if it has subagents that are currently working... If our activity detection is wrong and there's actually work happening in the background, hibernation is going to kill that work" (31:08). Dhruv agreed: fix subagent activity detection first, hibernation proceeds after.

Synced from the Oct 2 call: https://discord.com/channels/1476302178913357958/1555642689368891463
Match: semantic, 0.85

Claude Code before/after in the macOS Electron dev build (Developer Mode on). After an interrupted turn and leaving Chat, the old build kept host PID 66753 alive for over 50 seconds. The changed build stopped PID 62880; reopening started PID 64348, Claude recalled FALCON-73, and leaving Chat stopped it again.

Local E2E after 5b58b84 (macOS, isolated Electron dev build, Developer Mode on):

• Claude ACP: replied, hibernated with host/provider processes exited, reopened with saved history, and recovered from a forced wake failure with the draft preserved.
• Codex app-server: replied, hibernated with no chat process left, reopened, and accepted a message sent while wake was blocked; it delivered after the host resumed without showing queue or wake details.
• Focused checks: backend chat/storage tests passed; 178 renderer chat tests passed.
• Process evidence: hibernated sessions had no process under the isolated data directory; reopening created a new host (for example PID 21928; wake-blocked host PID 33914).

Recording of the isolated dev app:
https://github.com/user-attachments/assets/a5e37160-9141-4d78-9ef3-f7e93223085b

Short diagnostics demo (macOS, Developer Mode on)

1. Active: Codex, its chat host, and MCP processes are visible with PIDs.
2. Hibernated: after leaving the Codex Chat, about 11 seconds later the Codex row disappears because those processes exited.
3. Woken: opening the chat recreates the row with new PIDs.

The attached video is 26 seconds and labels each phase. The screenshot shows the same three states side by side.