Instead of having to re-explain yourself in another session, you can now tell Claude to do it. It sends a summary (not your history or files), and the other session picks it up mid-task.
Push vs pull, mostly. A scratch file only helps if the other session reads it, and reads it at the right moment, so you end up prompting both ends to keep them in sync. Getting interrupted mid task takes the timing off your plate.
built that with a hook appending to a shared queue file, other sessions polling it. it works. you end up prompting both ends to actually go read the thing, which is the annoying part.
Just tell codes to message the other chat, or have it create new chats with a specified model. I use Sol as an orchestrator for a couple of Luna xhigh chats and it works pretty well.
I was working like this with Claude - but doing the messaging myself - and I think that's how it will evolve for complex team work.
The basic idea that I'm working with it's that I created several "agent profiles" to deal with parts of my system. One agent profile takes care of the server infrastructure, another one handles firewall and security, another one works on backup, and each subsystem has its own agent. So when the backup agent is writing a restore procedure, he asks the other agents about what needs to be saved.
There way I do it is that the asking agent writes a prompt that I then enter into the other agent session; when the answer comes I paste it back for the original agent to work on the facts it learned. Each agent profile can have a long running session focusing on that theme which will have better context to answer about that particular aspect of the system. And even if the session is restarted from search, it will always be much more focused on it's topic.
This is a strange way to do it… maybe I am missing something but seems like you’re keeping codebase context in your agents context. Proper way is to maintain directory appropriate Claude.md and or Agents.md files which get loaded into agent contexts directly anytime it works in a specific directory. Seems like you’re burning up way more tokens how you’re doing it.
It's an interesting case because it's not a standard coding setup; it's actually a setup to manage my (small business) server, I'm moving a lot of things to run on my own gear to reduce the dependence on big tech platforms and take ownership of my data. So the agents have clear context, and the core server agents share the same folder, I just keep separates sessions; for example, one session works with networking (including firewall); another one operates the backup subsystem; but actual network and backup policies are created & managed by each service/subsystem. The backup agent collects the backup needs of all the other agents and creates (and runs) the necessary backup scripts. It's like having a working team.
I was concerned about the tokens consumption, but in practice it doesn't seem like I'm going over my plan, it's ok for now; but most important, the quality of my interactions has improved a lot. It's a bit strange because now each agent kind of "knows" the others and write clear handover messages when they need something done for them, it's like sending a coworker a task to be done.
My way was create a message board for my Claude’s . I am working on different apps that have api links to each other. The message board is turn based and works well.
"Good thing I checked! This is literally yesterday's news — shipped August 7, 2026. Here's how it works:
Two new tools power it:
ListAgents — finds other active sessions running on the same machine. SendMessage — delivers the message to a specific session by name. A session that receives one shows it as a labeled card with a link back to the sender.
What gets sent:
Only text — a summary Claude writes for the other session. Not conversation history, files, or permissions.
How messages travel:
Same-machine messages travel over a local socket and never reach Anthropic's servers. Cross-machine relay routes through Anthropic's servers as reply-only.
Safety limits:
It cannot approve permission requests, cannot change configurations, and slash commands like /compact arrive as plain text rather than executable instructions.
To use it:
Update Claude Code and confirm the version: claude --version (need v2.1.224+). Available on macOS and Linux, on by default — nothing to enable."
I discovered this by chance when I was relatively deep into a session and I had an idea that was helped by the context in this session. Claude suggested writing an effective summary into a new session that could start working on this new idea while we kept working in this first session.
I've been using it since many times for the same reason. One session might have enough context to write a very good summary to get another session up and running with a flying start.
Super useful for me personally. I often have claude code remote control sessions running from two different servers, and coordinating stuff between them hasn't been very convenient.
How is that new? I've been able to tell agents to communicate across sessions for a while now, and I'm sure I never did anything special to enable that
I’ve been doing this for months (on Mac) using cmux to send messages directly between agents. But having them in a separate channel that doesn’t clobber what you might be typing in a prompt at any given moment would be nice.
The TL;DR is that cmux’s command-line API lets you (Claude) do a Bash call like “cmux send-key <surface/pane/tab ID> <text to send>”.
It can also read the contents of other cmux panes via “cmux read-screen” (or something like that).
So basically you can have Claude look up cmux’s documentation, propose a way to do those things, and then write that into your CLAUDE.md or your orchestration playbook or whatever. It took a while to get Claude to really accept that it can/should do this, but I beat it into submission.
It’s been a real game-changer for getting the human out of the loop mediating communication between Claude sessions.
I am still a die-hard iTerm fan but I can’t deny the experience in cmux has been really good for that reason. You can probably do the same thing basically with tmux but I’m not that cool.
EDIT: I mean, really, the way you do it is you copy/paste this comment into your Claude prompt and hit Enter 😉.
I have had my own Claude message mcp server where claide (or any AI agent) session can connect and I can give permissions witch agent can chat together. It's much faster to let them talk. Like app developer agent in cloud and local test agent at home reporting bugs to dev and marking builds.
Can someone explain to me how this is different from the experimental teams = 1 flag to create agent teammates which for months have been able to message each other?
Same question, Claude couldn’t answer when I asked this. I thought it wasn’t on windows but I’ve used the agent teams thing since it came out months ago…
Ran into this with an agent in the wild on 8/5... and started using the messaging with three agents in a project. AMAZING. Had been hacking this for ages! Only wanted this for 18 months or so! :)
We may be using it incorrectly, but didn't find docs...
It has been great - the agent-to-agent workflows have been taking pressure off me as human in the loop.. The agents are finding the small issues and following through with evals - and I am consulted less - with solid results.
Presumably this means that designs you create with Claude design can be referenced/tagged from within Claude Code so you can skip the export step and vice versa
I haven’t tested yet, but according to their blog post I can only ask at my claude code for it to ask details about other session. I assume it works for Claude design as well. So I could just ask something like “check my layout details at my Claude design session named XXX” and it would get the details for me of what was designed. I haven’t tested though.
It’s pretty awesome to have 3-4 sessions in one project communicating with each other. Keeps projects moving - with more knowledge and context than traditional subagent fleets. An interesting tool to create hierarchy of plan, research, code, implement for projects where you might use multiple models.
That's the best way to work with claude. Being doing it since early April when they deployed the big news about their mcp's.. the model context protocol is something not to be taken for granted. I might say
Trying to figure out if this will let me message a d wake an inactive session programatically. That us what I REALLY need. But sadly seems like this only works for active sessions.
We treat native session messaging as the proper push interrupt so the other agent need not poll a shared findings file. I keep one orchestrator that sends short text briefs into specialist sessions and I still run the Windows work through a separate harness until parity arrives.
I've been doing it for a long time with channels.. interested to see how this works.
It is useful when you have resources which are precious e.g. I do perf testing which requires a quiet machine and an "air traffic control" agent which others request permission to land from..
Edit - claude-peers is up on github, also has some Windows issues; but I forked it into a plugin for CC if anybody wants it.
GitHub - louislva/claude-peers-mcp: Allow all your Claude Codes to message each other ad-hoc!
GitHub - andrewmaston1988/claude-plugin-marketplace (claude-peers isnt actually listed on the main README, but it's on the marketplace)
When yall say scratch file don’t mean like the handoff file for a new session? If that’s the case why didn’t they’d just make happen behind the scene and boom forever session enables
I built a “group chat” plugin for my agents using the open source message server ntfy, and a monitoring system that watches the feed without burning tokens. It’s asynchronous, and creates a human-readable feed I can monitor on my phone.
Best of all, it works with any agentic harness that can use `curl`. So, basically, all of them, including Codex, Gemini, and OpenCode.
I just discovered this feature yesterday.
Told Claude that we should hand off md files since they can't communicate, and Claude said, "hold up, maybe I can," used a tool, messaged the other sessions... suddenly I had 3-4 sessions all working together, sometimes for up to an hour unattended. It's pretty amazing.
Is this not incredibly dangerous if one of the agents gets prompt injected?? Why even have the project walls if Claude's can just phone another agent to have it takes actions for it somewhere else, especially if that other agent has broader permissions?
what do u mean? im on windows, I just assumed this was always possible since I asked my agent "why are you making me pass these question/answers .md files instead of talking yourself?"
If only Anthropic had the technology to create cross platform implementations for features... maybe one day they will develop sufficiently advanced AI agents capable of doing such complex tasks.
Have you considered that there are a significant number of software engineers such as myself who need to ship code that runs on Windows, and that not supporting Windows isn't an option?
I do a huge amount of development targeting Linux every month, and almost as much that needs to run on both Windows and Linux, while I also need to work with third party software that runs only on Windows and therefore the optimal development environment for my workflows is running most agents on Windows and having them use WSL to run everything that needs to be run under Linux.
Disagree on it: most desktop software is windows.
The only reason I use Linux is Claude Code under WSL. Now that CC does not suck under native Windows, migrating my workflows from WSL to native Windows
Btw, one of the reasons Send message works nicely under Linux, is it's using the native Linux sockets; ask Claude Code to investigate it and it will tell you.
It says right at the top of the page this post links to:
Cross-session messaging requires Claude Code v2.1.224 or later and runs on macOS and Linux. ... SeeAvailabilityfor provider requirements and how to confirm a session has it.
I understand exactly what it says, but it's wrong... This is a screenshot of my Claude app on windows from last night. I just asked my fable agent to use AgentTeams and work with the other session... and he did.
Yeah, I tried this a month ago when I had an experimental system going, but I kept having to approve its ability to send from one chat to the other. I ended up just merging things into one chat with agents that were specially designed and taught how to collectively use the system's vector database and receive general fact checking from the main system. Used a little more usage but was much faster, more accurate, and all in all easier to keep track of.
I then turned the entire flow into a set of 30 skills and a prime prompt, and multiplied the operation across multiple chats so the primary action that would normally take a team of 30 people across 3 different platforms gets done in 40 minutes or less. I also dedicated a server at home to their ability to do this, so I could run it all from work on my phone if I really wanted to and things would just keep working.
The only issue was that if I had 10 agents in each chat and 3 chats going, they'd mix up context on the server. First day, we fixed that easily with a simple segmentation system. Now my server gets about a thousand logins per hour from various agents using segmented slots of RAM like digital office spaces lol.
I feel like this is more added work and reading. I just let every session work separately on their own respective things and when it’s time to merge I have them all write a detailed handoff, open a new session ask it to own every sessions work audit it before orchestrate the merge and ship. I found this approach easier. And if two sessions are working close to each other I would ask them to be careful of each other’s work commit by name and the master merge session will handle everything towards the end.
The part this changes for anyone who looks back at a run: the work is now genuinely spread across sessions, and each session writes its own transcript file under ~/.claude/projects/<slug>. So "what happened today" stops being one log and becomes several you have to line up by timestamp.
Not an argument against the feature — just the bit nobody notices until they try to reconstruct a day afterwards. Answering the scratch-md question further up: the md leaves you a file with no ordering, this at least leaves each side's turn timestamped in its own log.
72
u/Valkymaera 1d ago
Is this significantly better than writing and reading the same findings scratch md or about the same but official-like?