bug1 — the registration belonged to the launch WRAPPER (its pid, a token in its tmpdir). When claude outlived it (restart, re-exec, resume) the reaper dropped the entry, the token vanished, and every send from that session went out silently under the MEMBER key; replies to it fanned out to all of the member's sessions. - services/session/reattach.ts: ensureSessionRegistered re-registers the session with its persisted keypair, a fresh attestation and claude's pid (nearest `claude` ancestor). Called by the MCP at startup (moves the anchor off the wrapper), by `send` when the session is unknown (auto-heal), and by the new `claudemesh session reattach`. - The session token lives next to the keypair (~/.claudemesh/sessions/<mesh>/<stem>.token) and survives the wrapper; token readers fall back to it via CLAUDEMESH_SESSION_ID (+ the new CLAUDEMESH_MESH_SLUG, or the mesh holding the keypair file). - `send` inside a session that can't be re-attached refuses unless --as-member; the daemon answers 401 session_unknown to a send whose session token it doesn't know. - The registry's absolute 24 h TTL is gone (liveness = pid + start time). bug3 — sessions reappeared under a new pubkey: - launch keys the keypair, the registration and the token on ONE id (it used to register a random UUID next to a keypair keyed elsewhere). - non-UUID session ids persist under a hashed stem instead of a throwaway keypair per call. - the daemon's boot reload is load-only — it never mints a key a live session didn't have. - a same-token, same-key re-register only moves the pid anchor, so the MCP's startup re-attach doesn't close/reopen the session WS. Tests: session-reattach.test.ts (2/5 fail on the old registry), keypair-store.test.ts updated to the new non-UUID rule. Spec: .artifacts/specs/2026-09-26-session-identity-and-routing.md §2, §4 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.7 KiB
3.7 KiB