[BUG] Desktop app: pinned sessions are unreachable to peers unless manually opened, and ListAgents gives no signal why

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 note first, because I think it matters: this is the Claude desktop app (1.30096.5), which bundles its own claude-code runtime (2.1.229). Every existing report I found in this area (#85886, #85497, #84945, #86019, #85160) is from CLI/native installs on 2.1.226-227. I could not find one from the desktop app, so the behaviour below may be desktop-specific.

In the desktop app, a user can have many sessions pinned in the sidebar. Only the ones currently open have a running process, and therefore only those bind a socket in /tmp/cc-socks/ and appear in a peer's ListAgents.

The mechanical part of that is understandable: no process, nothing to deliver to. The problem is that nothing communicates it. From inside a session, ListAgents returns:

No reachable agents.

That is the same output you get when peer messaging is genuinely broken. There is no way to distinguish:

• "you have no peers running right now" (normal, user just needs to open one), from
• "peer messaging is failing" (a real bug, e.g. #85497 where the socket never binds).

The practical effect is that cross-session collaboration silently looks broken. In my case the user has ~14 pinned sessions across 6 repos and assumed peer messaging had regressed, because the sidebar showed all of them while ListAgents reported none. It took a manual inspection of /tmp/cc-socks/ and ps to work out that the sessions simply were not running.

There is also no way to reach or wake a pinned session from another session. The only path is for the human to go and open each one by hand first, which defeats the purpose of asking one session to coordinate with another.

What Should Happen?

Either of these would fix the confusion:

1. List not-running sessions explicitly. Have ListAgents return known sessions that are currently unreachable, marked as such (not running / unreachable), instead of omitting them. Then "No reachable agents" only ever means the real failure case, and a session can tell its user "your peer exists but isn't open" instead of implying messaging is broken. This is the same request #85886 makes for daemon-hosted sessions, extended to closed desktop sessions.

1. Or allow waking a pinned session, so SendMessage to a known-but-closed session spawns it and delivers, rather than failing.

At minimum, the empty case should be worded so it distinguishes "no peers are running" from "peer discovery found nothing", because right now those are the same string and only one of them is actionable by the user.

Error Messages/Logs

Steps to Reproduce

1. In the Claude desktop app, have several sessions pinned in the sidebar across one or more repos (mine: ~14 across 6 repos). Leave all but one closed.
2. From the one open session, ask Claude to call ListAgents.
3. Observe: No reachable agents. — despite the sidebar showing every pinned session.
4. Inspect the socket directory and process list to confirm the cause is that the others are not running:

$ ls -la /tmp/cc-socks/
srw-------  1 user  wheel  0 Aug 15 08:05 68672.sock

$ ps aux | grep claude
68672 .../claude-code/2.1.229/claude.app/Contents/MacOS/claude --output-format

One socket, one live PID, one open session. No sockets exist for the pinned-but-closed sessions.

1. Manually open 3 of the pinned sessions in the sidebar.
2. Inspect again:

$ ls -la /tmp/cc-socks/
srw-------  1 user  wheel  0 Aug 15 08:05 68672.sock
srw-------  1 user  wheel  0 Aug 15 09:17 69839.sock
srw-------  1 user  wheel  0 Aug 15 09:17 69934.sock
srw-------  1 user  wheel  0 Aug 15 09:17 70034.sock

Three new sockets, timestamped at the moment the sessions were opened.

1. Call ListAgents again from the original session. Now exactly those 3 appear, and messaging to them works normally.

The behaviour is consistent and reproducible: reachability tracks "is the session currently open", and the user gets no indication that this is the rule.

Related, same session, possibly worth splitting out: peer identifiers are derived from the repo directory plus a per-instance suffix, so two different sessions in the same repo differ only by that suffix, and the suffix changes between instances. Over one day, the same repo produced nexus-legal-prod-8b and later nexus-legal-prod-8c for two different sessions the user had named "Publi Legal" and "Nexus Legal" in the sidebar. Combined with the above, addressing a specific peer requires it to be running and requires re-listing at that exact moment; an identifier noted earlier cannot be reused. I believe #86736 and #85160 already cover parts of this.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.229 (Claude Code) — bundled runtime inside Claude desktop app 1.30096.5. Note: npm latest is 2.1.233, so the desktop channel currently trails the published package by 4 patch versions; the app reports itself as up to date.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_