[Bug]: dev-electron supervisor survives its parent and keeps restarting Electron#19109

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. Start the desktop dev app from a checkout: vp run dev:desktop --home-dir <some dev home>.
2. Kill the parent vp process without letting it forward a signal — kill -9 <vp pid>, or close a terminal that dies before it can signal its children.
3. Collect the supervisor PIDs and check their parent:

   1	ps -o pid=,ppid=,command= -ax | grep 'dev-electron.mjs'

4. Touch one of the watched build artifacts: touch apps/desktop/dist-electron/main.cjs.
5. Repeat steps 1 and 2 a few times without cleaning up in between.

Expected behavior

This is the maintainers' call. Two directions, offered for discussion rather than as a proposal: have the supervisor exit when its parent goes away, and/or extend cleanupStaleDevApps() to reap stale supervisors of the same dev root as well as their apps.

Actual behavior

apps/desktop/scripts/dev-electron.mjs handles SIGINT, SIGTERM and SIGHUP and shuts down cleanly (:261-269). It has no parent-death watch, so when the parent vp process dies without forwarding a signal the supervisor is reparented to ppid 1 and keeps restarting Electron on the next file change (:188-202, debounce :50).

cleanupStaleDevApps() (:92-100, called at startup on :258 and twice inside stopApp(), at :168 and :177 — so on every debounced restart via :197, not only on shutdown via :247) only clears stale Electron apps of the same dev root, via pkill -f -- --t3code-dev-root=<desktopDir>. It does not clear stale supervisors. Several orphans therefore coexist, each restarting Electron and each killing the others' window on its own startup, all against the same T3 home.

Stopping the three orphans by their captured PIDs let the next run start cleanly with the same database: POST /oauth/token returned 200 once and zero SessionBootstrapError.

The 401 that surfaces while orphans are running is filed separately as #19110: this issue is the stale process, that one is why the symptom is undiagnosable.

One note while reading :97: that line uses pkill -f with the worktree path as the pattern, which is the exact shape AGENTS.md forbids contributors in "The three ways to hurt yourself", point 1 ("Your own agent process has this worktree's path in its argv"). Whether the script itself should be held to that rule is a separate question; flagging it because an agent that reads AGENTS.md and then this script gets contradictory guidance.

Impact

Major degradation or frequent failure

Version or commit

7b6d907574

Environment

macOS 26.3.2 (Darwin 25.3.0), Apple Silicon; Node 24.13.1; pnpm 11.10.0; vp 1.1.0 — the global install resolved from the bare vp in step 1 (command -v vp → /opt/homebrew/bin/vp, vp --version → vp v1.1.0). The checkout also ships its own ./node_modules/.bin/vp, which reports vp v1.0.0; that one was not used for this run.

Logs or stack traces

Workaround

Before each start, check that no dev-electron.mjs is running and that the dev ports are free, and stop a run by the PID of the vp process plus the supervisor PIDs collected at startup.