Claude Desktop blocks SendMessage entirely, which also removes subagent continuation

Claude Desktop blocks SendMessage entirely, which also removes subagent continuation

Summary

Claude Desktop launches the bundled Claude Code CLI with --disallowedTools SendMessage, and
additionally auto-denies the tool through an internal PreToolUse hook. The deny message explains the
block in terms of cross-session reachability:

Use mcp__ccd_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).

But SendMessage does two unrelated jobs. Blocking the whole tool also removes the second one —
continuing a previously spawned subagent with its context intact — which has nothing to do with
reaching terminal sessions, and which the replacement MCP tool does not cover.

The result is that the model is instructed to use a tool that cannot exist in this surface: the
Agent tool description still says *"Use SendMessage with the agent's ID or name to continue a
previously spawned agent with its context intact", ListAgents still says "send with
SendMessage({to: ...})"*, and every subagent result still ends with
agentId: <id> (use SendMessage with to: '<id>', summary: '...' to continue this agent). All of that
is dead text in Claude Desktop, and the model has no way to know it until it tries.

Environment

| | |
|---|---|
| Claude Desktop | 1.46388.4 (Windows MSIX, Claude_1.46388.4.0_x64__pzs8sxrjxfjjc) |
| Bundled Claude Code | 2.1.260 (%APPDATA%\Claude\claude-code\2.1.260\claude.exe) |
| CLI on PATH | 2.1.263 (%USERPROFILE%\.local\bin\claude.exe) |
| OS | Windows 11 Pro 26200 |
| Account | claude.ai, no managed settings |

What I observe

The desktop app spawns the CLI as (abridged):

...\Roaming\Claude\claude-code\2.1.260\claude.exe --output-format stream-json --verbose
  --input-format stream-json --model claude-opus-5 --permission-prompt-tool stdio
  --allowedTools mcp__computer-use,mcp__ccd_session__spawn_task,...,mcp__ccd_session_mgmt__send_message,...
  --disallowedTools SendMessage
  --permission-mode auto ...

So SendMessage is never registered, and ToolSearch with select:SendMessage returns
No matching deferred tools found. A second layer in app/resources/app.asar denies it even if it
were reached, emitting desktop_ccd_permission_auto_denied with reason: "cli_native_send_message".

Meanwhile ListAgents stays available and happily lists 29 reachable peers, telling the model to
message them with a tool that is not there.

Why this is not a CLI regression

I ran both bundled binaries headless and read the actual tool list from the init event:

| binary | flag | SendMessage present |
|---|---|---|
| 2.1.258 (the last version where it worked) | --disallowedTools SendMessage | no |
| 2.1.260 | --disallowedTools SendMessage | no |
| 2.1.260 | (no flag) | yes |
| 2.1.263 (terminal) | (no flag) | yes |

The CLI honours the flag identically in 2.1.258 and 2.1.260, so the CLI version is not the variable.

Timeline

Counting real SendMessage tool calls (not mentions) across all local transcripts:

| CLI version | sessions | SendMessage calls |
|---|---|---|
| 2.1.246 | 9 | 7 |
| 2.1.247 | 3 | 9 |
| 2.1.255 | 1 | 7 |
| 2.1.258 | 4 | 84 |
| 2.1.260 | 7 | 0 |
| 2.1.263 | 2 | 0 |

Last real call: 2026-09-03. Claude Desktop 1.46388.4 was installed 2026-09-05 20:11. Every session
from 2026-09-06 onward has zero, while subagent results kept advertising use SendMessage with to:
the whole time.

I could not compare against the previous desktop bundle (MSIX keeps only the current version), so I
cannot say whether the older app lacked this code or had it behind a flag that flipped — only that
the CLI is not the cause and the behaviour changed with the app update.

Steps to reproduce

1. Open a Claude Code session in the Claude Desktop app (Code tab).
2. Ask it to call ToolSearch with select:SendMessage → No matching deferred tools found.
3. Spawn any subagent with the Agent tool and let it finish. The result ends with

agentId: <id> (use SendMessage with to: '<id>' ... to continue this agent).

1. There is no way to act on that instruction.

Expected: either SendMessage is available for subagent continuation, or the surface stops
advertising it.

Suggested fixes (either would do)

1. Narrow the block to what the message describes. Allow SendMessage when to addresses a

subagent spawned by this session; deny only cross-session/peer targets. That matches the stated
rationale exactly.

1. If the whole tool must stay blocked, suppress the instructions that depend on it in this

surface — the use SendMessage with to: hint on subagent results, and the sentences in the
Agent and ListAgents descriptions — and say in their place that a subagent cannot be
continued here.

Option 1 is the one that restores lost capability; option 2 at least stops the surface from
contradicting itself.

Impact

On a project that leans on subagents, follow-up questions to a running agent are gone: a subagent
that returns an incomplete result has to be killed and respawned with a rewritten brief, paying its
whole context again. That is a real cost, and it is invisible until you try — the model is told the
capability exists right up to the moment it isn't there.

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