BrainBar GUI orphans + socket litter: manual 'open' during deploy leaves a second menubar app running indefinitely

[EtanHey]

Observed live 2026-08-19 by Etan ("there are now two brainbars at the same time").

Root cause: the 1.5.8 deploy runbook works around the agent-spawn _dyld_start hang by launching BrainBar via Terminal.app open. That instance is NOT launchd-managed (registers as application.com.brainlayer.brainbar.<n>) and nothing ever reaps it — PID 13335 ran from Aug 17 19:47 until manually killed Aug 19 21:5x, alongside the launchd-managed app (com.brainlayer.brainbar). Two menubar icons, two app processes, indefinitely.

Also found: 168 stale /tmp/brainbar-test-*.sock files from test runs (Aug 17-19) and 8 orphaned brainbar-hybrid-<pid>.sock files whose owning PIDs were long dead. Cleaned manually this session.

Asks:

1. Deploy path should not leave an unmanaged GUI instance — either fix the agent-spawn hang so launchd can own it, or have the runbook hand the process to launchd (and refuse to start a second instance if one is already registered).
2. BrainBar should single-instance itself: on launch, if another BrainBar is already running, either exit or take over — never silently run two menubar apps against the same DB.
3. Tests must clean up their sockets (tmpdir fixture or atexit); the hybrid helper should unlink its socket on exit and sweep brainbar-hybrid-*.sock whose PID is dead at startup.
4. Wave 4.5's self-verifier should assert exactly one GUI instance + one daemon holding /tmp/brainbar.sock — this is the same existence-vs-liveness class as Stale /tmp/brainbar.sock makes cask postflight hang and purge the install #714.

🤖 Generated with Claude Code