[BUG] SendMessage tool referenced but not available — agent continuation broken since resume parameter removal

This is happening to me. I work on agent definitions for my company and when they don't work I need to I need to be able to talk to them about what happened. I went on vacation for a week and my whole process broke. I can no longer resume agents.

Same issue. 2.1.84 on macOS.

 I don't have a SendMessage tool available in this environment, so I can't resume the previous agent. The tool described in the Agent documentation isn't present here. 

Bump.

Problem

∴ Thinking…

  The user is asking whether I have access to a SendMessage tool. Let me check what tools I have available.

  Looking at my available tools: Agent, Bash, Edit, Glob, Grep, Read, Skill, ToolSearch, Write.

  I don't see SendMessage listed directly, but it might be a deferred tool. Let me check.

  The deferred tools listed are: AskUserQuestion, CronCreate, CronDelete, CronList, EnterPlanMode, EnterWorktree, ExitPlanMode, ExitWorktree, NotebookEdit, RemoteTrigger, TaskCreate,
  TaskGet, TaskList, TaskOutput, TaskStop, TaskUpdate, WebFetch, WebSearch, and some MCP tools.

  SendMessage isn't showing up in either list, so I'll need to search for it to be sure.

⏺ Let me check.

⏺ No — SendMessage is not available in this session. It's not in my direct tool set nor in the deferred tools list.

  The docs describe it as a way to continue a previously spawned agent by sending a follow-up message to it. In my environment, the equivalent capability is handled through the Agent
  tool — I can spawn new agents but can't send messages to already-running ones via a separate SendMessage tool.

  If you need to interact with a running agent, I'd need to spawn a fresh one with the relevant context included in the prompt.

❯ Are you sure?                                                                                                                                                                         

∴ Thinking…

  Let me do a broader search to be more thorough.

⏺ You're right — I was wrong. The broader search didn't surface a SendMessage tool specifically, but I should have been more careful before asserting definitively. Let me check if it's
   referenced under a different name or is part of the Agent tool's capabilities.

  Looking back at my Agent tool description, it does say:

  ▎ "To continue a previously spawned agent, use SendMessage with the agent's ID or name as the to field — that resumes it with full context."

  So SendMessage is referenced in my instructions as a capability, but it doesn't appear in my actual tool set or deferred tools. It's described in the docs but not available to me in
  this session.

❯ Try to run a subagent. Let it read a file. Then resume it.                                                                                                                            

∴ Thinking…

  The user wants me to test the SendMessage capability. Let me spawn a subagent, have it read a file, and then try to resume it with SendMessage. First, let me spawn an agent.

⏺ Let me try. First, spawning an agent:

⏺ Agent(Read CLAUDE.md test)
  ⎿  Done (1 tool use · 14.4k tokens · 7s)
  (ctrl+o to expand)

⏺ The agent completed and returned an ID: abf00e69fe06a8032. Now let me try to resume it with SendMessage:

⏺ No SendMessage tool exists — not as a direct tool, not as a deferred tool. The agent result even says "use SendMessage with to: 'abf00e69fe06a8032' to continue this agent", but the
  tool itself isn't available.

  Conclusion: SendMessage is referenced in the Agent tool documentation and in agent results, but it's not actually provisioned in this session. I can spawn agents but cannot resume
  them with follow-up messages. To send more work to an agent, I'd need to spawn a fresh one with the full context included.

Cause & Solution

  SendMessage exists — it's a fully implemented tool at src/tools/SendMessageTool/SendMessageTool.ts. It's not missing or removed.                                                    
                                                                                                                                                                                        
  It's gated behind "agent swarms" — SendMessageTool.isEnabled() returns isAgentSwarmsEnabled() (SendMessageTool.ts:536). That function (src/utils/agentSwarmsEnabled.ts:24) requires:  
  - Ant (internal) builds: always enabled                                                                                                                                               
  - External builds: requires both CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS env var (or --agent-teams CLI flag) and a GrowthBook feature flag (tengu_amber_flint)                           
                                                                                                                                                                                      
  Since SendMessage has shouldDefer: true (line 533), it only appears in the deferred tools list when isEnabled() returns true — which for external users it almost never does.         
                                                                                                                                                                                        
  But the Agent tool prompt always references it — src/tools/AgentTool/prompt.ts:267 unconditionally includes:                                                                          
                                                                                                                                                                                        
  To continue a previously spawned agent, use SendMessage with the agent's ID or name...                                                                                                
                                                                                                                                                                                        
  And the agent result footers (AgentTool.tsx:1328, 1368) unconditionally emit:                                                                                                         
                                                                                                                                                                                        
  agentId: xxx (use SendMessage with to: 'xxx' to continue this agent)                                                                                                                  
                                                                                                                                                                                      
  (The only exception: one-shot built-ins like Explore/Plan skip the footer per constants.ts:6-12.)                                                                                     
         
  Root cause: The Agent tool's prompt and result formatting don't check isAgentSwarmsEnabled() before referencing SendMessage. They always tell the model to use it, even when the tool 
  isn't provisioned.                                                                                                                                                                  
                                                                                                                                                                                        
  The fix would be straightforward — in prompt.ts:267, conditionally include the SendMessage line only when isAgentSwarmsEnabled() is true, and similarly gate the agentId footer in    
  AgentTool.tsx:1366-1372. This would also save tokens for the vast majority of external users who don't have swarms enabled.

Related: https://github.com/anthropics/claude-code/issues/44080

Bump to prevent auto-closing.

https://code.claude.com/docs/en/sub-agents#resume-subagents

When a subagent completes, Claude receives its agent ID. Claude uses the SendMessage tool with the agent’s ID as the to field to resume it. The SendMessage tool is only available when agent teams are enabled via CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.

Definitely happening here too, raised https://github.com/anthropics/claude-code/issues/50622 initially.

Happened here as well. It messed up my custom setup and drastically increased my token usage.

This is really painful. It's been more than a month since claude could resume an agent. You guys ever going to fix this?

I had this error today too:

SendMessage isn't available in this environment — the Agent tool docs reference it, but it's not loaded. So I can't resume the 6 paused subagents directly. I have to either respawn fresh agents (loses prior planning context) or finish their work via Bash from outside. Let me first check the current worktree state and what docs they actually wrote to disk before deciding.

That's not good. Why does it say SendMessage is a thing?

I'm using Claude Code through VSCode. I have the desktop app too. Should I be using that?

I'm on Windows 11 25H2.

Still present:

• Agent tool documentation explicitly references SendMessage as the mechanism for continuing held agents
• SendMessage doesn't appear in tools, deferred-tools, or ToolSearch
• Every long-running coordination workflow has been silently doing fresh spawns with full-context-in-prompt
• Impact: doubled context loading, dead-pointer references in artifacts, lost "stop and resume" pattern

Predominantly using Claude Code 20x (across 2 different subscriptions and 2 days) -- NOT RESOLVED.
Dear Antropic Team: PLEASE FIX.

+1, this is still biting external orchestrators hard as of 2.1.143. A few data points from running Claude Code as a subprocess from a separate scheduler that needs multi-round subagent conversations:

Confirming rebeccasofiab-stack's observation: SendMessage is documented, referenced in result strings, named in agent-type descriptions, and ToolSearch/Agent additionalProperties: false both reject it. There is no working "continue this agent" mechanism anywhere on the surface. The product behaves like it has one; it doesn't.

Concrete operational impact for orchestrator-of-Claude patterns:

1. Every "resume" becomes a fresh spawn with full context re-injection. A 50-turn research subagent costs ~50× more tokens to "continue" than it should, because there's no way to hand the parent a pointer back into the child's existing context. We've measured ~2-3x weekly token usage growth on multi-subagent workflows that used to lean on resume:.
2. Agent IDs printed in result strings become dead pointers. The model trusts the docs and produces artifacts that reference subagent IDs as if they could be addressed later. They can't. Downstream prompts that say "ping agent X" silently no-op or, worse, get pattern-completed as if the ping succeeded.
3. The "stop and resume" coordination pattern (parent dispatches → checks back later) is structurally unavailable. It's the natural shape for any long-running multi-agent workflow and the docs claim it exists. Today the only working substitute is filesystem-mediated handshake state (parent and child read/write the same JSON) which a) burns context on routing the parent has no opinion on and b) re-introduces all the race conditions SendMessage was supposed to abstract over.

Adjacent issues that are the same family:

• #55992 / #59307 — transport-side drops that leak in-flight subagent calls (same "no continuation mechanism" symptom under a different cause).
• #59907 — auto-distributor injecting orchestrator task descriptions as fake teammate messages, which is what people end up doing manually when SendMessage isn't real.
• #29423 / #59309 — subagents not inheriting parent project rules; orthogonal but compounds the pain because re-spawning a "continued" agent doesn't even get back to the same starting state.

Suggested resolution: either (a) restore the resume: <agent-id> parameter on the Agent tool — the additionalProperties:false schema change can keep the rest of the strictness and just whitelist resume — or (b) actually ship SendMessage as a non-deferred tool with a stable address space for agent IDs. Half-shipped is the worst of both worlds: the docs train users (and the model) to depend on a primitive that doesn't exist, and the failure mode is silent regression to expensive respawns.

This has been broken since v2.1.77 (March 2026). Two months of orchestrators worldwide quietly burning 2-3x token budget on workaround respawns adds up.

I see the following description in the official documentation: The SendMessage tool is only available when agent teams are enabled via CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.
After setting the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS environment variable, I can indeed see the SendMessage tool. It seems this issue can be temporarily resolved this way.

hitting this a lot more lately here - i have the teams var unset too. But the docs and code seem to imply this is the 'new' resume agent path, and the model always tries to use it that way!

I'm also regularly facing this issue. Seems like a commercial decision not to fix it and force us to recreate subagents.

Duplicates of this are being filed and closed every week, and yet _nothing ever happens_ on this one.

I am (like others here) finding it harder and harder to believe that this isn't being ignored purposefully because it's a token-burner. This is a truly embarrassing mistake to have made its way into Claude Code in the first place, but it's downright _baffling_ that such important functionality (main agents being able to communicate with subagents beyond the first message without enabling an unrelated experimental flag, and therefore needing to wastefully kill and respawn/reorient a new subagent in their place instead) has been left fundamentally broken for >3 months while duplicate issues are filed (and auto-closed) over and over and over again.

Every day hundreds if not thousands of sessions kick off subagents, but anytime a subagent halts before finishing its work, for any reason whatsoever, the main agent has no way to resume or re-task it unless the user has enabled agent teams, because SendMessage, the method that the harness is still told is the way to communicate with and resume subagents (and which does in fact succeed in doing so, when unlocked by the agent teams flag) got incorrectly locked behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. As a result, standard subagent routing workflows are quite broken unless the user knows to enable the agent teams flag. Anyone who doesn't will frequently have the main agent reporting that SendMessage isn't found, contrary to their instructions, and will see that it is forced to kill and recreate any subagents that don't finish their work in one shot - sometimes repeatedly. Obviously this can pointlessly burn a _lot_ of tokens vs simply being able to use SendMessage (as documented) to instruct the halted subagent to resume or try something different.

Despite how utterly trivial it should be to fix this gross blunder and make SendMessage generally available again, it being erroneously gated behind the agent-teams functionality remains stubbornly uncorrected. _Why?_

thanks for elaborating on this @dysangelist-1 - how do we get more attention on this issue?

I've seen it less often but also seen similar ish ones after compact (forgets tool call schema requirements etc) if that helps...

I have two max accounts, and had this problem after switching accounts and resuming a session with subagents.

I'm also seeing this issue more often now

interns at anthropic who made this DO SOMETHING

It looks like we may soon be forced into teams by default: https://github.com/anthropics/claude-code/issues/68721#issuecomment-4738437180

I get this often.

I use about 200 million tokens a week. It's disgraceful that this has not been fixed. I run 6-7 agents in parallel at times (always on 1M context). Even my subagents and agent teams are configures to run on Opus. I used to be annoyed. Now I am genuinely angry this has not been resolved. I have posted THREE (3) times about this issue + in the Anthropic Discord as well. Some months we spend thousands on tokens. It is NOT ok!

Found a concrete cause for this in one environment — measured, not inferred. It may not be the cause for everyone in this thread, but it is cheap to rule in or out, and it was invisible from inside the session.

The Claude Desktop app launches its Code-tab sessions with SendMessage explicitly denied.

I hit the exact symptom described in the report (ToolSearch finds nothing, direct call errors) and went looking at the actual process command line instead of at settings. The bundled binary is started with, among other flags:

claude.exe --output-format stream-json --verbose --input-format stream-json \
  --effort high --model claude-opus-5 --permission-prompt-tool stdio \
  --allowedTools <mcp tool list> \
  --disallowedTools SendMessage \
  --setting-sources=user,project,local --permission-mode auto ...

All five concurrent Code-tab sessions on the machine carried the same --disallowedTools SendMessage. Environment: Claude Desktop 1.49585.0.0 on Windows 11, bundled Claude Code 2.1.260 (CLAUDE_CODE_ENTRYPOINT=claude-desktop, CLAUDE_CODE_CHILD_SESSION=1).

Why this is worth checking before assuming a runtime bug:

• The version requirement is met. The docs require v2.1.224+ (macOS/Linux/WSL2) or v2.1.234+ (native Windows). 2.1.260 clears that, so version is not the explanation here.
• The error text matches a deny rule exactly, not a missing tool. Calling it gives No such tool available: SendMessage. SendMessage is disabled for this session, in subagents as well as here. The cross-session-messaging docs state that denying SendMessage "also removes messaging to subagents and agent-team teammates, since the same tool serves both" — which is precisely the "in subagents as well as here" clause.
• Only SendMessage is denied, not ListAgents. ListAgents works fine in the same session and returns the full peer list. The documented way to turn messaging off names both tools; denying exactly one of the two looks deliberate rather than accidental. (This is also what distinguishes it from #90481, where ListAgents is the one that disappeared.)
• No settings file is involved, which is why it's invisible from inside. --setting-sources=user,project,local is passed, and none of those files mention tool permissions — so checking settings.json for a deny rule (the documented remedy) finds nothing, and the CLI flag can't be overridden from a settings file anyway.

How to check whether this is your case:

• Windows (PowerShell):

``powershell
Get-CimInstance Win32_Process |
Where-Object { $_.CommandLine -like '*claude-code*claude.exe*' } |
ForEach-Object { if ($_.CommandLine -match '--disallowedTools\s+(\S+)') { $Matches[1] } else { '(none)' } }
``

• macOS/Linux: ps -eo args | grep -- '--disallowedTools'

One caveat on the Windows snippet: it will also match the PowerShell process running the query itself, since the search string appears in its own command line. Ignore that row.

The part that seems worth fixing regardless of whether the deny is intentional:

When SendMessage is denied, the harness still tells the model to use it — repeatedly and authoritatively. The Agent tool description says to use SendMessage to continue an agent; ListAgents says names are "the address" for SendMessage; and every single agent result ends with use SendMessage with to: '<id>' ... to continue this agent. So a session is instructed, in three places, to call a tool that its own launcher removed. The failure mode that produces isn't just a wasted call — a workflow built on multi-round agent conversations degrades silently to "spawn a fresh agent with empty context", and nothing in the transcript marks where that happened.

In our case this had a measurable cost: a review protocol that depends on later rounds reaching the same reviewer had been quietly falling back to new reviewers with no memory of earlier rounds, and the metric built to detect repeated findings across rounds was therefore undercounting. We only found it because someone tried the call by hand.

Suggestion: when SendMessage is unavailable in a session, suppress the continuation hint in agent results and in the Agent/ListAgents tool descriptions — or replace it with the fallback that actually works. A tool description that promises a mechanism the session cannot use is worse than no mention at all, because it reads as authoritative and is never contradicted.