### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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` das

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

Status Fixed / completed

Reported on v2.1.226

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Aug 11, 2026 · closed Aug 17, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

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:

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.)
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).
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

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).
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).
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.
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.
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_

View original on GitHub ↗

3 Comments

SuzieKJJ · 2 months ago

Correction to the "two rosters" paragraph: the interactive/idle same-named entry we called a "stale fork remnant" turned out to be the user's own live terminal client attached to that very session — we later killed it during cleanup and the user's window closed instantly (engine survived via daemon; no data loss). So the roster disagreement is better described as: the dashboard lists daemon jobs, while ListAgents lists socket-registered processes including the user's own TUI clients, presented as same-named "sessions" with no marker distinguishing them from fork remnants. That ambiguity is itself hazardous — it misled both our sessions repeatedly, and finally caused us to kill the user's windows.

bcherny collaborator · 1 month ago

Thanks for the detailed report. This matches a bug we fixed in 2.1.228: a session that started before Claude Code had fetched the feature flag that turns cross-session messaging on (typically the first sessions after installing/upgrading to a version with the feature — 2.1.224–2.1.227) could come up without binding its inbox socket. That session could still send, but had no /tmp/cc-socks/<pid>.sock, so it never appeared in other sessions' ListAgents and couldn't receive SendMessage. Sessions started later (like your Session A) got the flag and bound normally, which is why the two looked inconsistent on the same machine. Since 2.1.228, a session binds its inbox as soon as the flag fetch completes, and long-lived sessions pick it up on the periodic refresh.

The uds:/tmp/cc-daemon-.../rv/<id>.sock path is the daemon's internal rendezvous socket, not a messaging inbox, so a send to it will always time out — that part is expected.

We couldn't reproduce on 2.1.233 in a short window (this needs a multi-day daemon-hosted soak with a cold flag cache), but the fix in 2.1.228 covers the mechanism described. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md ("Fixed cross-session messaging sometimes starting without an inbox in the first session after install or upgrade").

Closing as fixed. If you still see a live daemon-hosted session with no /tmp/cc-socks socket on 2.1.228+ (check with /status → Peer address in that session), please reply with the version, claude doctor output, and ls /tmp/cc-socks/ and we'll reopen. The roster note in your comment (a still-attached terminal client for the same session showing as a same-named entry) is worth tracking separately if it persists.

🤖 Generated with Claude Code

github-actions[bot] · 9 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.