Cross-session messaging (agents_cross_session_inbox) is enabled on Linux but not Windows for the same account

Summary

Same Anthropic account, two machines, both on Claude Code 2.1.234. Cross-session
messaging is active on the Linux machine and inactive on the Windows one.

On Linux: every live session gets a socket under /run/user/<uid>/cc-socks/,
$CLAUDE_CODE_MESSAGING_SOCKET is populated, and ListAgents + SendMessage
address other live sessions on that machine. Delivery is immediate — the
recipient sees a <cross-session-message from="uds:…"> block on its next tool
turn. Roughly 30 sends in one working day, all delivered.

On Windows: no session has a socket, ListAgents is not present in the tool
set, and SendMessage only addresses subagents/teammates.

Why it matters here

We run three machines (one Linux workstation, two Windows) with several
concurrent Claude Code sessions each. Because the Windows machines have no
native channel, we built a git+file message bus with a blocking background
process as a wake mechanism. It works, but it can only wake a session that
deliberately armed a waiter; the native channel can reach any live session.
That asymmetry is the reason we ended up creating a second coordinating session
per Windows machine.

What we measured on the Windows machine

Claude Code 2.1.234, win32, BUILD_TIME 2026-08-17T01:20:38Z.

• $env:CLAUDE_CODE_MESSAGING_SOCKET — empty, in every session.
• ~/.claude/sessions/<pid>.json — messagingSocketPath empty for all 10 live

sessions.

• No matching named pipe among the 363 present.

The feature is in the shipped binary, and it does have a Windows
implementation — so this does not look like a platform limitation:

• Default socket path generator returns \\.\pipe\cc-msg-<hex>.
• --messaging-socket-path help text: "a Unix domain socket on Mac/Linux, a

\\.\pipe\ name on Windows".

The startup path selects a "skipped" branch that logs:

[uds-messaging] Skipped: cross-session messaging gate off (will late-bind if a GrowthBook refresh enables it)

with telemetry key agents_cross_session_inbox. Passing
--messaging-socket-path explicitly does not bypass that gate — the gate check
sits inside the branch the flag lets you reach.

Questions

1. Is agents_cross_session_inbox rolled out per platform, per installation, or

per account? Ours differs between two machines on the same account.

1. Is there a supported way to opt in on Windows — a settings key, an env var,

or an enrolment we can request?

1. If it is a staged rollout, is Windows in scope, and is there anything useful

we can report from our side?

Not a crash and no data loss — this is a "which knob, if any" question. Happy to
provide more detail from either machine.