bug: browse stop exits 1 and retries after successful shutdown #2254

Activity

1. time-attack commented on Jul 15, 2026

   

   time-attack

   on Jul 15, 2026

   Contributor

   More actions

   @16francej Close this because it duplicates or has been superseded by the selected issue covering the same shutdown retry behavior.
2. p20240440-cpu commented on Aug 6, 2026

   

   p20240440-cpu

   on Aug 6, 2026

   More actions

   Confirming this on Windows 11 (gstack v1.60.1.0, fresh ./setup install), so it isn't macOS-specific. One difference from the original report: on Windows stop exits 0, not 1, while printing the same two lines. The daemon is genuinely gone afterward and no chrome-headless-shell processes are left behind.

   Root cause

   stop is dispatched as an ordinary command, and the handler exits the process before the response is ever written.

   browse/src/meta-commands.ts:

   case 'stop': {
     await shutdown();
     return 'Server stopped';
   }

   shutdown() ends with process.exit(exitCode) (browse/src/server.ts, end of the async function shutdown body). So return 'Server stopped' is unreachable and the HTTP response is never sent — the client always sees the socket drop.

   The CLI has no special case for stop (grepping cli.ts turns up only comments and help text), so the dead socket falls into the generic crash-recovery branch in sendCommand, which is guarded on ECONNREFUSED | ECONNRESET | 'fetch failed':

   1. stop → server exits → client sees the connection drop
   2. isProcessAlive(oldState.pid) is now false, so the busy-vs-dead probe from Headed browser "keeps crashing": HTTP-unresponsive daemon → orphaned Chromium → SingletonLock → restart crash-loop, and silent headless respawns #1781 correctly concludes "dead" and takes the restart path
   3. Client prints Server connection lost. Restarting... and launches a fresh daemon + Chromium
   4. It re-sends stop to the new daemon, which exits the same way
   5. retries >= 1 → Server crashed twice in a row — aborting

   So the CLI resurrects the exact daemon the user asked it to kill, then kills it again. Beyond the misleading message, the practical cost is a full Chromium cold start on every stop.

   Note restart has the same shape but wants this — its comment says "Signal that we want a restart — the CLI will detect exit and restart". stop inherits that behavior without wanting it, which is probably why this went unnoticed.

   Possible fixes

   1. Client-side (most robust): special-case stop in sendCommand so a connection drop after dispatching stop counts as success. The server is guaranteed to die, so a dropped socket is the expected outcome rather than an error.
   2. Server-side: write the response before tearing down — e.g. schedule shutdown() on the next tick / after flush so 'Server stopped' reaches the client first. Riskier, since it introduces a window where the daemon is alive but committed to exiting.

   Option 1 avoids depending on shutdown ordering at all.
3. garrytan

   added a commit that references this issue on Aug 16, 2026

   fix(browse): stop --force-restart kills the live daemon directly inst…

   ...

   a5b6522
4. garrytan

   closed this as completedin #2604on Aug 17, 2026
5. garrytan

   added a commit that references this issue on Aug 20, 2026

   v1.68.2.0 fix: tunnel revoke exists and revokes everything — setup ke…

   ...

   51932ec