Claude Code Sessions Can Now Message Each Other

There's a specific kind of developer video that circulates in AI-adjacent communities right now—someone with 100+ active sessions running simultaneously demonstrating a workflow that would have sounded like science fiction eighteen months ago. Ray Amjad's latest entry in that genre is genuinely worth paying attention to, not because the title promise holds up perfectly, but because the underlying capability it's built around is a meaningful architectural shift.

Anthropic recently extended Claude Code's messaging tools—previously reserved for subagent-to-coordinator communication within a single agent team—to work between independent sessions. The change sounds incremental. In practice, it opens up a topology that's different enough from traditional subagent orchestration to warrant thinking through carefully.

What the Feature Actually Does

The core mechanic is straightforward. Claude Code now exposes list_agents and [send_message](https://code.claude.com/docs/en/cross-session-messaging) tools that work across separate sessions, not just within a hierarchy of spawned subagents. Two sessions running completely independently—potentially on different machines, definitely with different contexts—can now pass structured messages between each other.

Amjad demonstrates this with a production monitoring handoff: one session watching logs over a 12-hour deployment window identifies issues, then dispatches a named fix session via send_message to open a PR in a fresh work tree. Clean separation of concerns, no context pollution. "It will use the send_message tool inside of Claude Code that was previously reserved just for sending messages to subagents and in between agents when it comes to agent teams to now send a message to the other session instead," he explains.

That "previously reserved" framing is doing real work. The agent teams architecture Anthropic shipped earlier established Claude-to-Claude communication as a first-class primitive, but within a structured hierarchy—spawned agents reporting back to a coordinator. What's shifted here is that the same plumbing now works laterally, between sessions that weren't necessarily spawned by each other.

The Case Against Subagents (and Its Limits)

Amjad makes a pointed argument at the video's midpoint. The traditional approach—claude -p or headless subagents via OpenAI Codex's execute flag—creates disposable workers that vanish when their task completes. You get the output but lose the thread. "When you have subagents, then it's really hard to follow up with a subagent asking more questions. The subagent often disappears from the view once it is done."

This is a real ergonomic problem, and it's more than cosmetic. The ability to return to a session, inspect its full decision path, and ask follow-up questions treats the AI session as a collaborative artifact rather than a function call. For exploratory or multi-phase work, that distinction matters.

But the headline—"subagents feel obsolete"—warrants some skepticism. Subagents remain superior for genuinely autonomous, fire-and-forget tasks where you don't need auditability. They're also more resource-efficient; keeping 108 live sessions running simultaneously (Amjad's count during the demo) isn't viable for most teams operating under API cost constraints. The peer session model is additive, not a replacement—it fills a gap in the middle of the autonomy/oversight spectrum that subagents left open.

Three Workflows Worth Watching

Amjad walks through several use cases. The most immediately useful is skill regeneration: pointing a source session at a skill file and telling it to send only the goal of that skill—not the implementation—to a parallel session, then seeing whether the second session arrives at a better strategy from scratch. "I could take this further and fan out in like three, four different ways—come up with four different strategies, spin up a bunch of Claude Code sessions, follow that goal, and then we can remake our skill."

This is essentially A/B testing for agent behavior, and it's clever precisely because it exploits the inter-session boundary as an information firewall. The receiving session can't be anchored to the existing implementation if it was never shown it.

The second workflow pairs session messaging with GitHub's recently shipped stacked pull requests feature. For projects being built in phases, the idea is to assign each phase to a separate session that opens a stacked PR when complete, then triggers the next session to start. Whether this survives contact with messier real-world codebases is an open question, but as a structured decomposition strategy it's coherent.

The third—and most architecturally interesting—is cross-machine communication. Amjad SSH's into a remote server, names the Claude session running there, and has his local session query it for specs. Two AI coding agents, running on different machines, coordinating directly without a human in the message chain. He's candid about the friction: remote control has to be explicitly enabled, and the permission model is still rough around the edges. But the primitive exists.

The Glue: cmux and the Peer Sessions Skill

None of this is turnkey. The workflow depends on cmux (a terminal multiplexer that lets Claude programmatically spawn and manage panes) and a custom skill Amjad published called "peer sessions" that teaches Claude Code how to combine cmux's CLI commands with the new messaging capability. Without these, Claude doesn't know how to launch its own new panes—you'd have to spin them up manually and then hand off the session names.

This is worth flagging because it means the "Claude managing itself" demo is partly a demo of what one practitioner built on top of new infrastructure, not out-of-the-box behavior. The distinction matters when you're assessing how much work it takes to reproduce these workflows.

The flip side: both tools are open source. The peer sessions skill in particular is a custom prompt structure, not a compiled binary—something any developer could inspect, fork, and adapt. That's exactly the kind of community building-block that tends to get absorbed into default tooling over time, either by the community or eventually by Anthropic itself.

What's Actually Being Automated Here

There's a frame worth holding onto as you watch this space develop. What Amjad is describing isn't just developer productivity tooling—it's a gradual shift in how humans relate to long-running AI processes. The subagent model treats AI sessions as tasks: you issue work, you get output, the session dies. The peer session model treats them more like colleagues with persistent context: you can check in, ask for updates, hand off, delegate, and return.

That's not a neutral change. It raises questions about oversight that the productivity framing tends to skip past. When 31 Claude Code sessions are running on one machine—24 reachable, negotiating tasks among themselves, opening PRs, communicating with remote servers—the human's role in that loop starts to look less like "developer" and more like "auditor who occasionally scrolls through."

That may be exactly the workflow Amjad and engineers like him want. It's also worth knowing what you're opting into.

---

By Dev Kapoor, Open Source & Developer Communities Correspondent, Buzzrag