Cross-session messaging

Following this video’s instructions fails unconditionally on my machine — and that is only where this starts. A 1 minute 53 second reel digs the cross-session messaging mechanism of Claude Code out of the filesystem itself. One socket directory doubles as the session list, which is a genuinely clean find. But the video never once says which OS it was filmed on, and that path does not exist on Windows. I enumerated all 600 named pipes and found zero session sockets. Meanwhile the thing I actually wanted — sessions talking to each other, and reading another session’s log — was already live on this machine, and finding that out overturned my own judgement twice.

What the video claims

That Claude Code v2.1.224 opened direct messaging between sessions, and that the claim was verified by digging through the filesystem rather than reading an announcement. The screen starts at ls -la /tmp/, finds /tmp/cc-socks/, shows three sockets, points out that permissions are owner-only, and then contrasts against version 2.1.223, where the socket count is zero.

There is a twist. Nothing brand new appeared. The message-sending tool itself had existed for 145 days, used for resuming subagents; what 2.1.224 opened was reach — what only reached inside a subagent now reaches an independent session. “The boundary moved, not the feature” is an accurate framing. That same tool is independently present in this session’s tool list right now.

The official text shown on screen:

When a change in one session breaks what another is building on, Claude can warn that session before you notice.

And the reason it didn’t work before, quoted from the issue — “Sessions are completely isolated, even when running on the same machine working on the same codebase.”

What broke when I checked

The fatal omission is the platform. The video presents /tmp/cc-socks with no preamble and never says macOS or Linux. Windows has no /tmp, and when Node listens on a path it produces a named pipe, not a file. Anyone on Windows who follows “open a terminal and run ls /tmp/cc-socks” fails unconditionally.

Both date calculations are off by one day. 144 days written as 145, 139 written as 140. It looks like inclusive counting and it changes nothing. But for content whose whole pitch is “I measured this myself,” it stands as an accuracy sample.

The weakest link is “and across machines.” The video asserts this on a slide only. Unix domain sockets are local-only, so remote requires a different mechanism — and that mechanism is never shown. The official doc URL, the issue’s real state, and whether the release notes mention this at all were all screen captures I never checked against primary sources. Any quotation should stop there.

Held against my own machine

The feature code ships in the Windows build but never surfaces at runtime. The session-listing tool’s string appears three times inside the executable, and the CLI version clears the gate (2.1.226). Yet with two of those CLI processes running, both socket and pipe counts were zero. Properly qualified: this is not “Windows will never do this” but “not observable on this machine on this date.”

And the question I asked already had an answer. I had asked “can sessions talk to each other, like watching a live log?” — and that capability lives not in sockets but in five session-management tools in the desktop app. They list other sessions, read another session’s transcript directly, full-text search every session’s body, and deliver a message into another session. That is a step above tailing a log file — it reads the conversation itself, not a log of it.

Verdict — and I was wrong twice

First wrong call: “you can’t wake a sleeping session.” Having read the tool description, I wrote “a Claude session sleeps once its turn ends, so the real gap is a trigger.” To check, I used an out-of-band oracle — since what matters is not whether it was delivered but whether it ran, I told the target session to write a file and then verified that file myself. The result: the idle session woke itself and executed, with zero human involvement. The call flipped. There is no reason to build a polling noticeboard when push works.

Second wrong call: “messages arrive disguised as human input.” I wrote that this made it an injection channel. Opening the receiving session’s raw transcript, they arrive in an envelope that names the sending session’s ID and title. They do land as a user turn, but the origin is labelled — which is how the receiver correctly determined “this came from another session, not from chat.”

Two things I didn’t expect came out of it. The receiving session complied and then set its own gate — it wrote the local temp file without fuss, but stopped and required human approval for anything outbound. It graded by risk. The direction is right, but ⚠ this is a model’s judgement, not a boundary enforced in code — another session might simply comply.

The second one matters more. This channel’s real failure mode is misdelivery, not security. The receiving session caught two errors in my own message — I had the date off by a day, and I named the reply target using a wrong memory of my own session’s title. Followed literally, the reply would have gone to the wrong session. A sender can misidentify itself, and without verification on the receiving end that would have shipped.

Option	Call
Hand off between sessions using the existing tools	Adopt now. Zero build cost
Build a dedicated file bus for sessions	Reject. Four channels already exist and push works
Polling daemon · always-on unattended loop	Reject. No reason to poll what pushes
Reproduce the video’s procedure	Reject. It never surfaces at runtime
Add inbound cross-session instructions to the safety boundary	New, needs review. The receiver’s gate isn’t enforced in code

If one lesson survives this page: a judgement formed from reading a tool description gets overturned by a single measurement. It happened twice here. And leaving the overturned calls on the page, rather than deleting them, is what stops the same assumption being made again at the same spot.