[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!