[BUG] Windows: cross-session messaging switches itself off in a session left open overnight (2.1.286)

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)
• [ ] I am using the latest version of Claude Code — observed on 2.1.286; 2.1.295 is out and I have not re-tested on it yet (see note at the end)

What's Wrong?

On native Windows, cross-session messaging switches itself off inside a session that has stayed open overnight. On the same machine, with the same version and the same settings, any newly started session keeps working.

In the long-lived session, ListAgents returns:

Cross-session messaging is switched off in this session right now — no sessions were listed, and this session is not reachable by name until it is switched back on.

That session still has its inbox, though. CLAUDE_CODE_MESSAGING_SOCKET=\.\pipe\LOCAL\cc-msg-… and CLAUDE_CODE_MESSAGING_TOKEN are still exported to its Bash tool. At the same moment, I started a fresh session from that session's own Bash (echo "Call ListAgents…" | claude -p --allowedTools ListAgents):

• it lists 6 peer sessions;
• one of them is the "switched off" session itself, shown as an interactive · busy peer;
• a SendMessage from the fresh session to another long-lived peer is delivered (queued there).

So the feature works on this machine, and other sessions can still see the old session's inbox. But the old session can no longer list peers or send messages.

What Should Happen?

A session that was able to message its peers should keep that ability for its whole lifetime. If a runtime gate does turn it off, the session should show the reason and offer a way to turn it back on from inside the session. The message says "until it is switched back on", but no documented control does that: /config has no "Messages from your other sessions" row, and crossSessionInbound is not set anywhere.

Error Messages/Logs

# long-lived session (open since day 1), day 4:
ListAgents -> Cross-session messaging is switched off in this session right now — no sessions were listed, and this session is not reachable by name until it is switched back on.

# same moment, fresh one-shot session started from that session's Bash:
$ echo "Call the ListAgents tool exactly once and print its raw output verbatim" | claude -p --model haiku --allowedTools ListAgents
-> 6 sessions listed, including the long-lived one as: interactive · busy · started 2d ago

Steps to Reproduce

Timeline from local transcripts. The version was the same throughout (2.1.286).

1. Day 1, afternoon: several interactive sessions message each other successfully. ListAgents lists peers and SendMessage returns queued there. One session (A) receives a handoff message.
2. Day 2, next morning: the PC had stayed on with session A open overnight. In A, ListAgents now returns "switched off in this session right now", on 4 attempts in a row.

• Between the last success and the first failure there was no user command, no settings change and no /config change.
• The transcript in that interval contains only normal turns and two away_summary entries.

1. Day 4: the same thing happens in another session, B.

• B was started on day 1 and received a cross-session message four minutes after starting (delivered, queued there).
• It then stayed open for three days.
• On day 4, ListAgents in B returns "switched off in this session right now" (3 attempts).
• A brand-new claude -p session works immediately, and lists B as interactive · busy · started 2d ago.

What I checked:

• crossSessionInbound is not set in any settings file (user, project or local). There is no managed settings file and there are no Windows policy keys, so the default should be accept.
• No SendMessage / ListAgents deny rules: both tools are present in the session.
• None of DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC or DISABLE_GROWTHBOOK is set in the environment.
• No session shows a "Messages from your other sessions" row in /config. The docs say the row should appear on ≥ 2.1.232 unless managed settings or --settings set the key, and neither applies here.
• I found no re-authentication prompt in the affected sessions' transcripts.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.286 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

• Installed via WinGet (native Windows). Windows 11 Home 10.0.26200.
• Sessions were opened from VS Code (CLAUDE_CODE_ENTRYPOINT=cli), with several sessions running in parallel on different projects. Default permission mode: auto.
• Workaround: relay through a fresh one-shot session. Write the message to a file, then run echo 'Read file X and SendMessage its exact content to <peer>' | claude -p --model sonnet --allowedTools Read SendMessage. The relay exits after sending, so the receiver must not reply to it.
• Possibly the same mechanism: #98261. There, the Artifact tool gets stuck "switched off in this session right now" after a forced re-auth mid-session, while new sessions work. A comment there reports that the tool state appears to be set when the session process starts and is not refreshed later. The symptom and wording here are the same, but for messaging and with no re-auth that I can see.
• Related, but different: #90481 (ListAgents disabled for every session, including new ones), #94828 (Desktop: delivery stopped surfacing in the recipient), #92409 (Windows: SendMessage missing while ListAgents shows peers), #99522 (Windows: lost contact with agents in long-running sessions).
• Version note: 2.1.295 has been released since. I will add a comment if a session left open overnight on the newer version still shows this.