[DOCS] Cross-session messaging between Claude Code sessions is undocumented

Documentation Type

Missing documentation (feature not documented)

Documentation Location

_No response_

Section/Topic

Cross-session messaging (sending a message from one Claude Code session to another)

Current Documentation

I could not find any documentation for this feature. Searching the docs and this repository for cross-session messaging, session-to-session messages, or how to send a message to another session returned nothing that describes it.

What's Wrong or Missing?

Claude Code sessions can send messages to each other, and nothing in the docs or the product says so.

I keep one session open per area of a larger project. I only found out that sessions can message each other by accident, months into using the tool. Once I knew, it changed how I work: one session now asks the others for status and collects a daily wrap-up and next-day prep. Five sessions reported back within a few minutes. Before that I was copying context between chats by hand.

Two specific things are undocumented, and both cost me real time today.

1. That the capability exists at all. There is no hint in the product when several sessions are open in the same project, and no mention in the docs.

1. How a reply gets back to the sender. I told five sessions to reply to a session id I believed was the right one. It was not, and there was no way to check: the tool that lists sessions excludes the calling session, so a session cannot look up its own id. Three sessions posted their replies into the wrong chat before one of them worked out on its own that replying to the requesting session is what actually works. That behaviour is not written down anywhere.

Suggested Improvement

1. Add a short section covering session-to-session messaging: what it is for, how a message arrives in the target session, and what happens when the target session is idle rather than open.

1. State explicitly how to reply. Something like: "To answer a message from another session, reply to the requesting session. A session cannot resolve its own id, so do not have a session hand out its own id as a reply address."

1. Document the idle case. A message delivered to a session that is not currently open is only processed when that session next runs, so a coordinating session should report which sessions answered and which have not.

1. Mention it in the changelog when it ships or changes, with one line on what it is for. A one-time hint in the product when a user has more than one session open in the same project would have saved me an afternoon.

Impact

High - Prevents users from using a feature

Additional Context

This is a thank-you as much as a request. Cross-session messaging has changed how I run a project with several parallel parts, and the sessions now catch each other's mistakes. Earlier today one session found factual errors in a document another session had produced, because it could check the figures against a source only it held and say so directly.

Image annotation in the Claude desktop app deserves the same note, though it may sit outside this repository's scope. Marking up a screenshot and handing it over beats describing where a UI problem is in words. For frontend work it is the difference between saying the padding is off and pointing at it. I could not find a guide for that either.