fix(browse): terminate orphan server when parent process exits

[mmporong]

Problem

Closes #807

On Windows, the browse server is spawned with detached: true so it survives after the CLI exits — which is intentional for the persistent-server design. However, when the Claude Code session itself ends, the server becomes a true orphan with no way to know it should stop. It keeps chrome-headless-shell.exe child processes alive, and each new Playwright browser spawn causes a console window to flash on screen.

Root Cause

BROWSE_PARENT_PID was never passed to the server process, so the server had no way to detect parent exit.

Fix

browse/src/cli.ts — pass BROWSE_PARENT_PID when spawning the server on both platforms:

• Windows (detached node launcher): injects BROWSE_PARENT_PID into the env object literal string
• macOS/Linux (Bun spawn): adds BROWSE_PARENT_PID to the env spread

browse/src/server.ts — parent-process watchdog (15 s interval):

const BROWSE_PARENT_PID = parseInt(process.env.BROWSE_PARENT_PID || '0', 10);
if (BROWSE_PARENT_PID > 0) {
  setInterval(() => {
    try {
      process.kill(BROWSE_PARENT_PID, 0); // signal 0 = existence check, no signal sent
    } catch {
      console.log(`[browse] Parent process ${BROWSE_PARENT_PID} exited, shutting down`);
      shutdown();
    }
  }, 15_000);
}

process.kill(pid, 0) is the standard cross-platform existence check — throws ESRCH on all platforms (including Windows/Node) when the PID is gone. The 15 s interval means the server exits within 15 s of session end, well before it would cause noticeable disruption.

Backwards compatibility

• BROWSE_PARENT_PID defaults to 0 → watchdog is a no-op if the env var is absent (safe for existing installs until they upgrade)
• No change to the idle-timeout behaviour
• Headed mode is unaffected (shutdown() already skips headed mode for the idle timer; the watchdog does not)

Tested on

• Windows 11 Pro — orphan server now terminates within 15 s of Claude Code session exit; no more chrome-headless-shell.exe console flicker

[garrytan]

Big thanks for this contribution, @mmporong! Your fix has been landed on the garrytan/security-wave-5 branch as part of our community security wave (commit 5bd05c9). We credited you as co-author. Ships in v0.15.12.0. Really appreciate you taking the time to find and fix this.

[Jud]

This feels like the likely cause of #867