Bind client effects to an immutable daemon incarnation

[schickling-assistant]

Problem

A client that selects a session from list --json cannot prove that a later connection reached the same daemon incarnation.

Today the socket path is mutable (<root>/<id>.sock), while STATUS.createdAt is read back from the current metadata record by id rather than held by the connected daemon. Re-listing before attach is therefore TOCTOU.

An isolated replacement probe demonstrated the stronger failure mode:

1. Connect an FD to daemon A.
2. Replace the registry-local id with daemon B.
3. The retained FD still talks to daemon A.
4. STATUS over that old A FD reports Bs new createdAt`.

So list -> connect -> STATUS -> ATTACH cannot currently validate the selected incarnation, even when STATUS and ATTACH share one FD.

Desired contract

Provide one immutable, opaque daemon incarnation and a client operation that binds a connection to an expected session reference before any effectful operation.

The smallest compositional shape appears to be:

• Generate a high-entropy opaque incarnation once per daemon.
• Publish the same value in registry metadata.
• Return it from daemon memory in STATUS; never re-read identity by mutable id.
• Let the client open the Unix socket, send side-effect-free STATUS, validate { id, incarnation }, then ATTACH/PEEK/DATA/RESIZE on that same already-validated FD.
• Expose this as a shared connect(SessionRef) API so every effect uses the same identity boundary.

A new wire message is not necessarily required. A BIND/HELLO exchange would enforce the rule server-side, but STATUS-then-effect on one immutable FD is a smaller compatible implementation if STATUS becomes daemon-authored.

createdAt should remain chronology rather than be overloaded as guaranteed identity; a separate opaque token makes collision and semantic guarantees explicit.

Non-goals

• No new geometry or attach role.
• No consumer-specific naming or metadata inference.
• No repeated list checks or timing window as a correctness mechanism.

Acceptance proof

A replacement-race test should retain an FD to daemon A, replace the same registry-local id with B, and prove:

• the A FD reports A`s immutable incarnation;
• a new connection expecting A rejects B before ATTACH/PEEK/DATA/RESIZE;
• a connection expecting B succeeds;
• legacy clients remain compatible under the chosen rollout policy.

Posted on behalf of @schickling

field	value
agent_name	co1-copper
agent_session_id	df4c8469-c18b-4474-b430-14ea1dfd3bc8
agent_tool	Codex CLI
agent_tool_version	0.145.0
agent_runtime	Codex CLI 0.145.0
agent_model	unknown
runtime_profile	/nix/store/v2g542rika3abxn98x5yimz431j5br13-coding-agent-runtime-profile/share/coding-agents/profile.json
skills_manifest	/nix/store/3aq75z8arl44fsvn49i2k4yqlzb1kcwb-agent-skills-corpus/share/agent-skills/manifest.json
worktree	dotfiles/schickling/2026-07-20-cos-misc
machine	dev3
tooling_profile	dotfiles@unknown-dirty