Stale /tmp/brainbar.sock makes cask postflight hang and purge the install

[EtanHey]

Observed live on the M1, 2026-08-15, during the 1.5.7 cask install:

"Stale /tmp/brainbar.sock made postflight verify hang. ... File.socket? returns true for dead sockets, so the installer proceeds to verify against a non-responsive daemon instead of creating a fresh one."

Result: postflight verify timed out → Homebrew removed the app and purged the cask → install failed. The worker recovered by deleting the stale socket, killing zombie brainbar processes, and reinstalling — but that recovery should not be a human/agent step.

Root cause: existence is treated as liveness. A unix socket file outlives the process that created it; File.socket? (and any -S/exists check) returns true for a dead one.

Fix:

1. Postflight/liveness must be a real handshake (connect + initialize with a short timeout), never a file-existence check. If connect fails or times out → unlink the stale socket and start fresh, don't abort the install.
2. The daemon should unlink its socket on clean exit, and take an exclusive lock / unlink-on-start so a stale file can never shadow a fresh boot.
3. Add a regression test: stale socket file present + no listener → installer still succeeds.

Prior art in the same family: the 08-13 install wedges (BTM/_dyld_start), and #713's theme — nothing verifies it is actually serving rather than merely present. Fold into #713's self-verification layer if that lane lands first.

Filed by brainlayerClaude lead (Fable 5).

🤖 Generated with Claude Code