Messaging your other Claude Code terminal sessions (no setting to turn on, no Haiku relay)

A post on X says that to let Claude Code sessions talk to each other you have to set crossSessionInbound to accept and have a Haiku session relay the messages. In fact, since v2.1.224 (v2.1.234 on native Windows), sessions on the same machine can message each other by default. There is nothing to turn on, and messages travel over a per-session local socket with no model relaying them. A delivered message counts toward usage like a prompt you type, so the "zero tokens" claim is wrong too.

1. Give each terminal's session a recognizable name. For a session that's already open, use /rename api-worker.

claude --name api-worker

1. Check which sessions Claude can reach. /peers works too. If the command isn't recognized, your version is too old, so start with claude --version.

/list-agents

1. Tell Claude what the other session should know. Type @ and the first letters of a session's name to pick it from the typeahead (v2.1.232 or later).

Let @api-worker know the schema migration finished

1. For long-running work, ask for one notice when the other session finishes (v2.1.236 or later in both sessions).

Tell me when the migration session finishes what it's working on

crossSessionInbound matters in a narrower case. When a session that bypasses permission prompts is involved, the default holds the message for approval, and a claude -p worker can't show the approval dialog, so a held message is dropped after five minutes. Start only the -p workers that must take messages unattended with accept.

claude -p "<task>" --settings '{"crossSessionInbound":"accept"}'

To stop receiving, set it to refuse; to stop sending and listing too, add SendMessage and ListAgents to your deny rules. Denying SendMessage also blocks messages to subagents and agent-team teammates.

{
  "permissions": { "deny": ["SendMessage", "ListAgents"] },
  "crossSessionInbound": "refuse"
}

A message from another session can't approve a permission prompt for you, and commands inside it such as /compact don't run. A session inside a container and one on the host can't reach each other.