Recover a live daemon whose pathname socket and registry were unlinked

[schickling-assistant]

Problem

A daemon and its PTY child can remain alive after an external cleanup unlinks
<name>.sock, <name>.pid, and <name>.json. The Unix listener remains bound
to its now-unlinked inode, but the pathname no longer resolves. New clients
report the session as not found and cannot attach.

Blindly rerunning the launch command is unsafe: it creates a second writer
while the original provider is still alive.

Minimal reproduction:
https://github.com/schickling-repros/2026-07-pty-unlinked-live-daemon

npm run repro

Confirmed on 7534050b663e7202f49a66541479944ca98619dc under Linux. The
reproduction is deterministic.

RCA

The listener is owned by the original daemon. After its pathname is unlinked,
another process cannot relink that socket inode or ask the daemon to rebind
through the lost pathname. /proc/net/unix can still show the listener, but it
is observation only. Recovery therefore requires cooperation implemented
inside the original daemon.

Proposed contract

Add an explicit, fail-closed live recovery operation:

• require a captured metadata snapshot containing the name's daemon PID and
  generation;
• mark metadata written by supporting daemons so the CLI never sends a
  recovery signal to an older daemon where that signal could have its POSIX
  default action;
• publish a short-lived authenticated request in PTY_ROOT for the expected
  daemon to discover through its own watcher; send no process signal;
• have the daemon validate name, PID, generation, process-start token when
  available, and launch identity;
• refuse if the pathname is now owned by a different listener or registry
  generation;
• rebind a new listener inside the same daemon, republish sidecars, and preserve
  the child plus existing client connections;
• prove the PID and generation did not change.

Hypotheses / acceptance

• H1: the daemon/provider die when registry paths are removed - disproven;
  both remain alive.
• H2: an external process can relink the unlinked listener - disproven by
  Unix pathname socket semantics.
• H3: daemon-cooperative rebind can restore attachability without restarting
  the child - confirmed as the implementation direction.
• exact PID and generation remain unchanged through recovery
• existing attached clients remain connected
• stale/wrong snapshots fail closed without signaling unsupported daemons
• a foreign replacement pathname is never unlinked or replaced

Posted on behalf of @schickling

field	value
agent_name	co2-bear
agent_session_id	a078daee-6f98-4916-91a8-d21291407789
agent_tool	Codex CLI
agent_tool_version	0.145.0
agent_runtime	Codex CLI 0.145.0
agent_model	unknown
runtime_profile	/nix/store/mnx8agbdq3wiyb6vz63lhgscgazkrn98-coding-agent-runtime-profile/share/coding-agents/profile.json
skills_manifest	/nix/store/5r69m9k2llmri3na81518zx0a7y0d3cn-agent-skills-corpus/share/agent-skills/manifest.json
worktree	pty/schickling-assistant/2026-07-30-swift-lamarr-46
machine	dev3
tooling_profile	dotfiles@0fb7e03