Español

Your Agents Can't Talk Without Names

You have three terminals open, all working on the same repository. One just changed a schema another is building against. Nothing tells it. You find out when something breaks, and the coordination layer between your agents turns out to be you, copying findings between windows by hand.

Sessions can message each other

Cross-session messaging lets one session deliver a message to another. The intended cases are exactly the ones that waste your time: handing over a finding when one session discovers a breaking change, coordinating parallel worktrees so each knows what landed, and getting status back from a long migration instead of watching it.

What travels is a piece of text one agent writes to another — never conversation history, never files. That's a deliberate boundary. If you want another session to have your whole context, you resume the session rather than message it.

You don't invoke any of this yourself. The agent discovers targets and sends on its own, and can decide to send without being asked — for instance right after making a change that affects work elsewhere.

But only a named session is addressable

Here's the part that stops people. A session answers to the name set with the /rename command or the --name flag. Without one, Claude Code names the session itself, and you're relying on a generated label you don't know.

So naming is the cheap prerequisite everyone skips. Name it when you launch it, or rename mid-flight, and an anonymous terminal pane becomes an endpoint you can hand work to:

# at launch
claude --name worker

# or mid-session
/rename worker

Then /list-agents — also available as /peers — shows what's actually reachable. The first line is this session's own name, which is what your other sessions use to reach it. The rows below are subagents, teammates, your other local sessions, and your cloud or remote sessions.

One nuance worth knowing: if two live sessions end up sharing a name, the agent adds a short identifier to distinguish them, and the listing shows each local session's working directory so you can tell them apart.

Where the messages actually go

This matters if you care about what leaves your machine:

• Same machine — over a per-session socket (a named pipe on Windows), never through Anthropic's servers.
• Another of your machines — through Anthropic's servers, arriving over that machine's Remote Control connection.
• A cloud session — through Anthropic's servers to the cloud session.

That first row is the common case and it's entirely local. The other two are why cross-machine reach has a prerequisite: a session on another machine appears only when it runs with Remote Control and this session is connected too. If yours isn't connected, a message still goes through but carries no reply address, so the far end can't answer.

The failure modes, in order of likelihood

• Not named — nothing to address. Start here.
• Version skew — messaging requires a recent version; an older long-lived session simply isn't reachable. Restart the ones you intend to coordinate with.
• Different filesystems — sessions register themselves in files on disk, so two sessions can only reach each other if they see the same files. A container and its host can't. Neither can WSL 2 and native Windows on one computer.
• Inbound controls — the receiving session may be set to hold or refuse. See the companion article on why a peer's message is never your approval.

The takeaway

An unnamed session is a room with no door. Name the ones you want to coordinate, run /list-agents to confirm they can see each other, and let the handoffs happen between agents instead of through your clipboard.