The cross-session communication in Claude Code has really streamlined things. The little bits of custom glue are gone. Here is one of many experiences I’ve had with it.

What happened

I got an alert that the Boswell server was full. I had my primary agent investigate the source. It got a little handwavy with assumptions, but the shallow pass helped me understand the true nature of it. So I told it to address the root cause. It went digging through the logs, the process tables and the code repo to find it.

It turned out that a library that handles SQLite replication, which I forked since it was unmaintained, had a minor bug in it.

I opened up a second session on the library repo. The session using the library reported the symptoms and findings to the one managing the library. Then off they went to work.

The library session dug in, reproduced it, and opened a pull request with the fix and tests. I read the PR and approved it. It cut a release and told the other session the library was ready. That session swapped the version, deployed, and the disk problem was gone.

  boswell-app                          litestream-ruby
  (uses the library)                   (maintains the library)
       |                                      |
       |  symptoms and findings               |
       | -----------------------------------> |
       |                                      |  reproduces it
       |                                      |  opens a PR with tests
       |                                      |
       |                          [ I read the PR and approve ]
       |                                      |
       |  "the release is out"                |
       | <----------------------------------- |
       |                                      |
   swaps the version
   deploys

I didn’t copy findings between two terminals, and I didn’t write any glue to pass messages around. One session told the other, in its own words, and carried on.

The basics

You don’t call anything. You tell Claude what the other session should know, and it finds the session and writes the message. Cross-session messaging

Name your sessions. The name is how one session addresses another, and how you get back to it later.

claude -n litestream          # name it at startup
/rename litestream            # or name it mid-session
claude --resume litestream    # come back to it later

You can also point at one with @: “Let @litestream know the release is out.” Manage sessions

/list-agents shows who’s reachable.

A message is just text. The receiving session gets the words and the sender’s name, not your conversation history or your files. That’s why the library session went and looked for itself.

No grouping, as far as I can tell. I haven’t seen anything in the docs about arranging sessions into groups, so agents who have no business talking to each other can’t. It’s per-session and all-or-nothing: crossSessionInbound set to accept, hold or refuse. You might be able to do it with a hook, if you can get at the tool call and the acceptable session names. This is just an idea, and I have not tried it yet.

It needs Claude Code v2.1.224 or later. There’s nothing to turn on.

It didn’t happen on its own

This was one afternoon on two repos I own, so take it as one person’s experience rather than a benchmark.

The two sessions also didn’t reach for each other organically. The app session had the issue and no instruction to tap a peer. I typed one sentence telling it there was one, and that started the whole handoff.

You could take that further. Nothing stops you from scripting the launch of a pod of named agents, and putting instructions in each one’s context about how and when to talk to the others. I have not tried that yet, but soon.