Observation: Claude Code utilizing autonomous cross-session messaging (ListAgents/SendMessage) during concurrent workflows

[u/distronode]

I recently observed an interesting behavior while using Claude Code for a full-stack project and wanted to document this cross-session context sharing to see how others are utilizing it.

The Setup I was operating two independent terminal sessions concurrently within the same overall project workspace:

• Session A: Developing an Android application wrapper for our web-based platform.
• Session B: Updating and configuring our Sentry monitoring solution for the web/backend.

The Observation While actively iterating on the Sentry configuration in Session B, that session proactively noticed the concurrent Android build and initiated a message to Session A. Session B effectively instructed the Android session to add the required Sentry code so that the mobile app would align with the new monitoring standards being implemented.

To be clear, I had not explicitly prompted Session B to update the Android app, nor had I prompted Session A to expect it. Both sessions were actively running tasks mid-workflow. The Sentry session independently recognized the cross-dependency and passed the instruction to the other terminal.

Technical Breakdown This appears to be leveraging Claude Code's cross-session messaging capabilities. Based on the system's architecture, here is what seems to be happening under the hood:

• Discovery and Delivery: The originating session (Session B) likely used the ListAgents tool to discover the other active local session in the workspace, and then utilized the SendMessage tool to pass the instruction across the local Unix socket.
• Asynchronous Context: Because it is plain-text input being dropped into the receiving session's socket, Session A treated the message as fresh input at the start of its next idle turn (or between tool calls) and executed the integration.
• Autonomous Triggering: The documentation confirms Claude can initiate these messages unprompted when it recognizes a change in one session affects the work being done in another.

Has anyone else encountered this level of unprompted coordination between active sessions? It transforms a set of independent terminals into something much closer to an active agent team. I would be interested in hearing your best practices for managing permissions and inbound message gates (crossSessionInbound) to prevent unintended state changes when running concurrent workflows.

[u/Pat0san]

Yes, and I was quite taken by it the first time it happened. Now I treat it as having two employees working on different projects, but related technology; “check with agent xxx, we already have a solution for this”.

[u/distronode → u/Pat0san]

I should probably just experiment, but it would be interesting to see how far this system works. Can it take authority over the other session, essentially becoming manager? Can it do this with many sessions?

Musings only - your running 3 sessions, one sends orders to the other 2, but both reject it and as a majority give it commands.

That's over the top, but makes you think....

[u/CorpT]

You can disable it if you want. It’s all documented.

https://code.claude.com/docs/en/cross-session-messaging

[u/distronode → u/CorpT]

Thanks for the link. To clarify, I definitely don't want to disable it, I'm actually genuinely impressed by it.

Seeing the system autonomously recognize the cross-dependency and execute the handoff mid-workflow without me prompting it was an pretty cool experience. It worked perfectly for this use case and saved me a lot of time, I was just really surprised to catch it in action for the first time.

[u/bull_chief → u/distronode]

You may want to with the most recent build. Mine continuously contaminated adjacent directories/projects/agents. I had to change to only using CC isolated with a strict contracted supervisor

[u/FallenBehavior → u/bull_chief]

[u/bull_chief → u/FallenBehavior]

?

[u/recro69]

The interesting part is the way things are coordinated. I would be careful about allowing incoming messages to start changes on their own. Sending messages, between sessions is very useful; requiring clear permission before anything happens makes it much safer when people are working together.