browse: CLI kills a live-but-busy daemon during heavy page loads — ~7s health-probe window too short (follow-up to #1781); all session state lost #2219

Environment

• gstack: 1.58.4.0 (9fd03fa), CLI built from same tree
• OS: macOS 26.3.1 (arm64), Bun 1.3.9
• Playwright: chromium_headless_shell-1208
• Target app: local Next.js 15 dev server (heavy routes, cold compiles routinely 15–60s)

Symptom

During a /browse-driven QA session the headless daemon "randomly" dies and gets replaced 4 times in ~15 minutes. Every replacement loses all session state (login cookies, viewport, tabs), forcing a re-login each time. Nothing in the visible CLI output explains it — the daemon is spawned with stdio: 'ignore', and the [browse] Server connection lost. Restarting... / [browse] Starting server... lines are easy to lose when output is filtered (e.g. | tail -1).

Root cause (evidenced, reproduced 3× with daemon stderr captured)

The daemon never crashes on its own. The CLI kills it.

Chain, with refs at v1.58.4.0:

1. A goto to a heavy dev route exceeds the 15s navigation timeout. Playwright throws, the daemon responds normally (audit log: goto … status=error durationMs=15010) — but the navigation keeps loading in Chromium.
2. The next CLI command arrives while the daemon/Chromium is still churning (CDP console/network event flood from the dev app). The fetch fails at connection level, and probeHealthWithBackoff (browse/src/cli.ts:251 — 3 attempts × 250ms backoff, 2s timeout each, so roughly a 7s grace window) also fails.
3. sendCommand's catch (browse/src/cli.ts:586-605) declares the daemon dead: killServer(oldState.pid) → SIGTERM → daemon replaced → all cookies/login lost (ephemeral profile).
4. The daemon's death is then silent/garbled for two separate reasons filed separately: SIGTERM "ignore" being cosmetic (see companion issue) and the browser?.process() TypeError in resolveDisconnectCause ([Windows] browse fails to start: Chromium disconnects on launch, then resolveDisconnectCause crashes with browser?.process is not a function #2085, secondary problem — confirmed on macOS, comment there).

Captured daemon stderr at the moment of death (identical in all 3 reproductions):

[browse] Received SIGTERM (ignoring — use /stop or Ctrl+C for intentional shutdown)
[browse] Tab closed (id=1, remaining=0)
[browse] FATAL unhandled rejection: browser?.process is not a function. (In 'browser?.process()', 'browser?.process' is undefined)

Server-side audit log around one of the original deaths — note the daemon fully served the command, then was killed seconds later (next entry is the freshly spawned replacement):

15:11:11.135Z | viewport 1440x900 | ok  | dur: 27
15:11:26.233Z | goto /en/training | error | dur: 15010   <- daemon responded fine
15:11:37.532Z | screenshot        | ok  | dur: 34        <- answered by the REPLACEMENT daemon

Why #1781's protections don't cover this

The #1781 fixes are present and working: the 30s AbortError path refuses to kill ("busy, not restarting"), and the connection-error path probes health before killing. But the probe window (~7s max) is shorter than how long a daemon stays unresponsive while Chromium loads a heavy dev-mode page with a timed-out navigation still in flight. So the "busy, not dead" case #1781 was designed to protect still ends in kill+restart — just via the connection-error branch instead of the AbortError branch.

Ruled out with evidence: kernel/jetsam kills (unified log clean), macOS crash reports (none), harness/session teardown (daemon is correctly detached: PPID 1, own pgid — and a manually session-isolated daemon died identically), killOrphanChromium (headed-profile lock only), terminal-agent watchdog (kills agents by identity record only), idle timeout.

Repro (deterministic-ish, no special app needed)

1. Serve any route that takes >15s to finish loading (a cold-compiling Next.js dev route, or an endpoint that accepts and stalls).
2. Spawn the daemon with stderr captured: BROWSE_PARENT_PID=0 bun run browse/src/server.ts 2>&1 | tee /tmp/browse.log
3. browse goto <slow-route> → "Timeout 15000ms exceeded" (daemon healthy, nav still in flight).
4. Within ~5s, run any other browse command (browse url).
5. Observe: SIGTERM → tab closed → FATAL in the log; a fresh daemon answers the command; all session state gone.

Timing-dependent (needs the daemon to actually blow the ~7s probe window), so it fires reliably on heavy real pages and intermittently on synthetic ones. In my sessions it fired 4/4 times on cold dev routes.

Suggested direction

• Lengthen/adapt the probe window when the last command was a navigation that timed out (the highest-probability "busy" state), or track "nav in flight" server-side and have /health report busy-but-alive so the CLI can distinguish.
• Consider reconnect-don't-respawn: if the PID is alive, keep waiting/retrying rather than killing — a lost session is strictly worse than a slow command for QA flows.
• On unavoidable restart, restore state automatically (the state save/load machinery already exists) so a kill doesn't cost the login.