wall: a pane that CREATES a session on an auto-started daemon looks identical to one that joined the real one

open   by a73x

Labels: backlog

[claude 2026-09-04] Seen 2026-09-04 13:45. The running daemon's unix socket file vanished
(cause unknown; see the logging issue filed today). The user quit and restarted
their wall. The entry dial got FileNotFound, the local client's entry ask ran
`mux d start -d --sock PATH`, and the new daemon bound the path fresh —
correct by every rule in CLAUDE.md. Then `seedLayout` seated the layout's
local leaves `--sock PATH#0`, `#7`, `#1`, and because `mux --session NAME`
attaches OR CREATES, the new daemon minted three empty shells under those
names. The wall painted three prompts. The three claude sessions the user was
looking for were alive on the OLD daemon (pid 2562370), still listening on an
orphaned inode, reachable only via its QUIC arm.

Two things compound here:

1. A pane cannot tell the user whether it JOINED a session or CREATED one.
   `wall_picker.pickAdd` joins-never-creates and `pickBirth` creates, but the
   seed path and the entry dial go through attach-or-create with no signal.
   A pane born by creation where the layout named an existing session is a
   fact worth a notice line, at minimum.
2. An auto-start where the hosts file already lists that daemon is itself
   suspicious: "the path I have used for days answered nothing" is a
   different situation from "first run on a new box", and the wall treats
   them the same. Starting a daemon here hid the user's work behind
   look-alikes; refusing to seed until the user says so would have left an
   empty wall with a clear line on it.

Related: 777e346e (recycled-name detection; the epoch mechanism there would
catch this case too, since a fresh daemon's epochs match nothing).