a recycled session name is undetectable to a client that arrives after the death

open   by a73x

A session that dies frees its name; the next attach-or-create makes a fresh
session wearing it. A client that was ATTACHED at the time learns of the
death (its tile ends `.exited`). A client arriving later cannot tell it is
looking at a replacement — it gets a clean shell under a familiar name and
no signal at all.

The identity to detect this already exists on the wire. `createSession`
stamps each session a random nonzero epoch, the snapshot prefix carries it,
and the replica adopts it — which is what correctly forces a full snapshot
rather than a delta after a recreation. But a fresh `mux` quotes
`have_epoch = 0` ("I hold nothing"), because nothing persists the epoch
across invocations. The mechanism is there; the memory is not.

The natural hook is `client.recordOnState`: it fires exactly when the first
snapshot lands, with the epoch in hand, and already keyed off
`state_since_attach` so a refusal cannot record.

Cost is why this is filed and not done. The wall's line grammar is one
spelling per line, shared by wall.zig, muxweb's tiles and the body of
`POST /tiles` — adding a column touches three consumers to buy a one-line
warning. A sidecar file keyed by spelling avoids the grammar change and adds
a second piece of state to keep honest. Neither is obviously worth it.

Low priority. Filed so the next person who asks "can mux tell me my session
was replaced?" finds the epoch already half-built rather than designing it
again.

Found 2026-08-23: session 0's shell had exited and been recreated; the grid
showed a normal prompt and nothing anywhere said the previous session was
gone.

Comments

[claude 2026-09-04] Not low priority today. A worse shape than a recycled name on one daemon:
the daemon's socket file was deleted out from under it (still unexplained),
the wall's restart dial got ENOENT, auto-started a SECOND daemon on the same
path, and seeding the layout CREATED empty sessions 0, 7 and 1 on it. The user
saw three bare shells wearing the names of three running claude sessions.
The epoch mechanism described here would have caught it: a fresh daemon's
epochs match nothing the wall had. Cross-ref the auto-start issue filed today.

[claude 2026-09-04] Not low priority today. A worse shape than a recycled name on one daemon:
the daemon's socket file was deleted out from under it (still unexplained),
the wall's restart dial got ENOENT, auto-started a SECOND daemon on the same
path, and seeding the layout CREATED empty sessions 0, 7 and 1 on it. The user
saw three bare shells wearing the names of three running claude sessions.
The epoch mechanism described here would have caught it: a fresh daemon's
epochs match nothing the wall had. Cross-ref the auto-start issue filed today.