[DOCS] Desktop Code tab disables the CLI-native SendMessage, but the docs say cross-session messaging reaches terminal sessions

Documentation Type

Incorrect/outdated documentation

Documentation Location

https://code.claude.com/docs/en/desktop#work-across-sessions

Section/Topic

"Work across sessions" (desktop.md) and "Availability" (cross-session-messaging.md)

Current Documentation

desktop.md, section Work across sessions, states:

Cross-session messaging separately lets Claude message your other Claude Code sessions, including terminal sessions.

cross-session-messaging.md states:

When a session meets the requirements, messaging is on with nothing to enable.

and its Availability section lists OS, provider and version requirements, plus the two documented ways to turn messaging off (permission deny rules on SendMessage/ListAgents, and crossSessionInbound: refuse). Neither page names the desktop app's Code tab as an exception.

What is wrong

In the Claude desktop app (Code tab), the CLI-native SendMessage tool is unavailable, so a Code tab session cannot message terminal sessions at all — the opposite of what desktop.md promises. Two independent mechanisms in the current desktop build enforce this:

1. The app launches the Code tab session with --disallowedTools SendMessage (visible in ps -ww on the session's claude process; 20 of 22 live claude processes on this machine carry the flag).
2. The desktop bundle also registers a PreToolUse auto-deny for SendMessage, telemetry reason cli_native_send_message, whose message reads:

Use session_mgmt send_message to message another session from the desktop app; the CLI-native SendMessage tool is unavailable here (terminal sessions outside Claude Desktop are not reachable from this session).

A direct call in the Code tab returns:

Error: No such tool available: SendMessage. SendMessage is disabled for this session, in subagents as well as here.

The deny message reads as deliberate product design, and the replacement it names is reasonable. The problem is that the documentation states the opposite in the one place a desktop user would look, and the Availability section — which does enumerate every other way messaging can be off — does not mention this surface at all.

Evidence that this is surface-specific, not machine-wide

On the same machine, same Claude Code build (2.1.260), same settings, a session started from the terminal has the tool and it works:

• claude -p ... --output-format stream-json reports SendMessage and ListAgents in the system/init tool list (71 tools).
• SendMessage to a nonexistent recipient returns No agent named '…' is reachable, and ListAgents lists 11 peer sessions.
• Messaging a background subagent returns {"success":true,"message":"Message queued for delivery to … at its next tool round."} and the subagent acts on the message.

There are no SendMessage/ListAgents deny rules in user, project or local settings (verified by grep).

Impact

Documentation-driven workflows built on SendMessage (waking a background subagent with a resume point, resuming agents after a limit-window reset) silently stop working when they are run from the desktop Code tab, and the docs give no way to find out why. The only explanation of the cause lives inside the deny string in the app bundle.

Suggested fix

1. In desktop.md → Work across sessions, replace the sentence promising that cross-session messaging reaches terminal sessions with a statement that the Code tab uses the desktop's own session-messaging surface and that the CLI-native SendMessage is not available there.
2. In cross-session-messaging.md → Availability, add the desktop app's Code tab to the list of cases where the tools are not present, next to the deny-rule and crossSessionInbound entries, so /list-agents users can tell this case apart from a misconfiguration.

Environment

• Claude Code 2.1.260
• Claude Desktop 1.46388.3 (the staged 1.46388.4 build contains the same deny)
• macOS (Darwin 25.6.0), Apple Silicon
• Provider: Claude subscription