Embassy v4.6.0

Embassy 4.6.0 — a restarted Claude session keeps its route

Restart a Claude Code session (to load an MCP server, say) while the old process is still alive, and until now Embassy saw two registry records for one session and dropped both: the session could neither be reached nor send, and every failure read "route unregistered". Retiring the route to fix it made things worse, locking that session out for a day.

Now — when two live processes share a session UUID, Embassy binds to the newest reachable process, revalidates the exact record before every write, and reports CLAUDE_SESSION_DUPLICATE in status, refresh and send with the selected and other PIDs and a reason: an older process is stale (exit it), the newest did not answer a probe (check it before exiting anything), or none answered. Sends keep working meanwhile. Daemons never displace an interactive session or gain caller eligibility.

Retiring a Claude route now fences only the old endpoint ID: a live session that reappears gets a fresh ID immediately; old deliveries and old conversation replies never retarget it. Codex retirement and successor semantics are unchanged.

Protocol — private control protocol is now 7 (bounded optional warnings). Update the CLI and broker together: npm install -g agent-embassy@4.6.0 then embassy service install. State schema 7 and federation protocol 3 are unchanged; no reset.

Documented limits — duplicate detection during a write is bounded to a 4096-entry registry window; siblings beyond it are unobserved until the next refresh.

Tested with offline suite 426/426 on Node 22 (macOS and Ubuntu); an end-to-end fixture with real registry files and sockets for the duplicate-process and retire-then-reappear scenarios; an adversarial review whose three findings were fixed and re-verified; a live drill on two Macs reproducing the incident.