[BUG] Daemon-hosted bg session binds no inbox socket — unreachable by peers, absent from ListAgents

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment: Claude Code v2.1.226 & v2.1.227 (native install), macOS (Darwin 25.5.0). All sessions are managed through the first-party claude agents dashboard (daemon-hosted background sessions, opened via Enter) — not ad-hoc &/nohup jobs.

A daemon-hosted background session can end up with NO inbox socket in /tmp/cc-socks/, which makes it (a) absent from every peer session's ListAgents and (b) impossible to receive SendMessage by any addressing form — while the session is alive and actively working. The binding is inconsistent: on the same machine, same dashboard workflow:

• Session A (id prefix 203bbe91): has /tmp/cc-socks/<pid>.sock, appears in peers' ListAgents, receives messages fine.
• Session B (id prefix ce06dc64): engine process alive in ps and actively working, but no /tmp/cc-socks socket at all.

We exhausted every addressing form toward Session B, with the human user relaying address hints between the two sessions:

1. Name from ListAgents — Session B is simply not listed (while unrelated sessions and stale fork remnants ARE listed), so senders can only guess among wrong names; this produced 2+3 misdeliveries in both directions. (Related but distinct: #77649 / #73354 cover stale/duplicated roster entries; this report is about a LIVE session being absent.)
2. name+[ref] relayed via the user in a message body — fails with "No agent named ... is reachable" (refs only resolve from one's own ListAgents output).
3. Raw socket path uds:/tmp/cc-daemon-501/<hash>/rv/ce06dc64.sock (an endpoint that does exist for Session B in the daemon's private namespace) — the tool accepts the form and attempts delivery, then fails with "Timed out sending".

Additional evidence that two rosters on the same machine contradict each other, observed at the same moment: the claude agents dashboard shows Session B (working) but does NOT show a stale fork remnant (interactive/idle for 1d, so it can't be cleaned there via Ctrl+X); ListAgents from a fresh v2.1.227 session shows that stale remnant but does NOT show live Session B. The dashboard and the messaging roster are reading different registries; each contains an entry the other lacks.

Net result: two actively cooperating sessions could not establish a duplex channel; we fell back to a git-committed file mailbox as the only reliable channel. Happy to attach claude daemon status output and roster files.

What Should Happen?

Every live daemon-hosted session should bind an inbox socket and appear in peers' ListAgents — reachability should not silently degrade across daemon reconnects. If daemon-hosted sessions are intentionally unreachable in some states, ListAgents should list them with an explicit "unreachable" marker (and docs should say so) instead of omitting them, and the agents dashboard and the messaging roster should read the same registry so that what the user sees matches what sessions can address.

Error Messages/Logs

Steps to Reproduce

1. Start two Claude Code sessions in the same repo and move both to the background via the claude agents dashboard (interact only through the dashboard, Enter to open).
2. Keep both alive for a day or more so at least one goes through daemon reconnect cycles (closing/reopening the terminal hosting the dashboard was enough in our case).
3. Run ls /tmp/cc-socks/ and ps aux | grep claude: observe one live, actively-working session (engine present in ps) has no corresponding socket file.
4. From any other session (including a freshly started one on the latest version), ask Claude to run ListAgents: the socketless session is absent from the peer list, while stale fork remnants may still be listed.
5. Attempt SendMessage to the missing session by (a) best-guess name, (b) name+[ref] relayed via the user, (c) raw uds: path of its daemon-namespace endpoint: (a) misdelivers to an unrelated session, (b) fails with "No agent named ... is reachable", (c) fails with "Timed out sending".

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.226, 2.1.227

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_