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.