[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Claude desktop app launches every Claude Code session with --disallowedTools SendMessage, and separately installs a PreToolUse hook that denies the tool by name. The tool is therefore unavailable in every session on the account, on every machine, including sessions the app launches on a remote Linux host over its bridge.

SendMessage did two separate jobs. The app replaced one of them and removed the other.

Session to session. Messaging another Claude Code session. The app substitutes its own MCP tool for this, and that substitute works.
Session to its own subagent. Sending a further message to a subagent this session already spawned with the Agent tool. Nothing replaced this. The app's substitute addresses a session id; a spawned subagent is not a session and has no session id, so it cannot be named.
The app's own denial text states the rationale: use the desktop tool to message another session, because terminal sessions outside Claude Desktop are not reachable from an app session. That rationale is entirely about the cross-session job and is a reasonable one. It says nothing about subagent continuation, which involves no other session, no other machine, and no reachability question at all — the subagent is a child of the session making the call. Disabling the tool wholesale to solve cross-session reachability also removed subagent continuation, which we believe was unintended.

The product still advertises the capability it has disabled. Every Agent tool result ends with agentId: <id> (use SendMessage with to: '<id>', summary: '<5-10 word recap>' to continue this agent). We resolved every occurrence in our session records back to the tool that produced it: 593 genuine Agent-spawn results carry that line, 64 of them after the block took effect, the most recent minutes before this was written. An orchestrating agent that reads its own tool output is told to use a verb the session cannot call.

The documentation says it should work. The subagent documentation at code.claude.com/docs/en/sub-agents states that Claude resumes a spawned subagent using SendMessage with the agent's id or name, and that "SendMessage doesn't require agent teams to be enabled; only structured team-protocol messages such as shutdown_request and plan_approval_response do." Several existing reports assume the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS gate is the cause; per that page it is not, and on our machines the cause is the flag above.

The runtime still supports it, and it was being actively maintained days before. SendMessage occurs at essentially identical frequency in the binary across 2.1.255, 2.1.258 and 2.1.260 (56, 55, 56 string occurrences). 2.1.255 was in use on 1–2 September while the tool was being called 168 and 188 times a day. The 2.1.257 changelog entry reads "Fixed a subagent that resumed another agent via SendMessage never being woken by that agent's completion" — so subagent resumption via this tool was a maintained, working feature immediately before the app began disabling it.

Related existing reports, none of which identify the blocking party: #35240, #36196, #37051, #38183, #42737, #50622, #61248, #90481, and anthropics/claude-agent-sdk-python#716.

What Should Happen?

Either scope the block to the cross-session use of SendMessage so that subagent continuation keeps working, or provide some other supported way for a session to send a further message to a subagent it has already spawned with the Agent tool.

Failing either, the Agent tool should stop printing an instruction to use a tool the session cannot call, so that an agent is not actively misdirected by its own tool output.

Error Messages/Logs

No such tool available: SendMessage

ToolSearch({query: "select:SendMessage"})
  -> No matching deferred tools found

Launch command line of a live session, read from the running process:
  --allowedTools mcp__computer-use,...,mcp__ccd_session_mgmt__send_message,...
  --disallowedTools SendMessage
  --setting-sources=user,project,local --permission-mode auto

Desktop app bundle, session manager — an unconditional append after two conditional ones:
  var xu = "SendMessage", Su = ["ListAgents","ListPeers"], Cu = [xu, ...Su]
  o.scheduledTaskId && (U.disallowedTools = ["AskUserQuestion"]),
  ((s ?? r.heldFirstStart)?.spawnedFrom ?? o.spawnedFrom)?.sharedCheckout &&
      (U.disallowedTools = [...U.disallowedTools ?? [], ...Xf]),
  U.disallowedTools = [...U.disallowedTools ?? [], xu];

Desktop app bundle, PreToolUse hook — a second, independent block:
  if (e.tool_name === "SendMessage")
    return { hookSpecificOutput: { hookEventName: "PreToolUse", permissionDecision: "deny",
      permissionDecisionReason: "Use <desktop tool> 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)." } }

Logged as: desktop_ccd_permission_auto_denied, reason cli_native_send_message

Steps to Reproduce

Start a Claude Code session from the Claude desktop app (any platform; observed on Windows and on a Linux host the app drives over its remote bridge).
Spawn a subagent: Agent({ subagent_type: "general-purpose", prompt: "..." }).
Read the tool result. It ends with agentId: <id> (use SendMessage with to: '<id>' ... to continue this agent).
Try to follow that instruction — call SendMessage, or run ToolSearch({query: "select:SendMessage"}). The tool is not present and is not in the deferred tool list.
Inspect the session's own launch arguments (/proc/<pid>/cmdline on Linux, or the process command line on Windows). The pair --disallowedTools SendMessage is present.
Confirm it is not yours: the string appears in no settings file at user, project or local scope.
The same session launched from a plain terminal outside the desktop app should not receive the flag. We have not verified that, because the desktop app holds the login on the affected machine.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.255 (in heavy use 1-2 September; 188 SendMessage calls on 2 September)

Claude Code Version

2.1.260 (pinned and launched by Claude desktop app 1.46388.4; latest published is 2.1.266, which the app does not let us select)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

The block is not something we set and not something we can unset:

--disallowedTools appears in no settings file on either machine, at user, project or local scope.
No preference key in the app's config or preferences store relates to it, and no user-facing string anywhere in the app mentions SendMessage. There is no toggle.
The only related preferences that exist (an admin tool-disable list, managed settings tool policy) can only ADD denials. Command-line denials are documented in the app's own code as surviving managed settings.
Setting CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS does not apply here: per the subagent documentation, SendMessage does not require agent teams, and the flag above blocks the tool regardless.
Cost, as a concrete example rather than a complaint: a long-lived specialist subagent held accumulated judgement across a multi-stage pipeline and was to be asked at the end for its conclusions and a handoff to its successor. The orchestrating session could not reach it. That work was lost, silently — no error, no warning. Every multi-turn subagent pattern now degrades to a fresh subagent re-educated from scratch at each consultation, at full context cost. One measured instance of that workaround cost 277,000 tokens to re-seat a specialist that could have been messaged.