claude-code - 💡(How to fix) Fix docs(sendmessage): clarify name registry semantics for completed agents

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

The SendMessage tool's documentation states "Refer to teammates by name, never by UUID." This guidance is accurate for concurrent multi-agent coordination, but it does not cover the resume-after-completion pattern, where the name registry has already deregistered the agent.

Error Message

After a background sub-agent completes, attempting SendMessage to: "<agent-name>" returns:

Root Cause

The SendMessage tool's documentation states "Refer to teammates by name, never by UUID." This guidance is accurate for concurrent multi-agent coordination, but it does not cover the resume-after-completion pattern, where the name registry has already deregistered the agent.

Code Example

{"success":false,"message":"No agent named '<name>' is currently addressable. Spawn a new one or use the agent ID."}
RAW_BUFFERClick to expand / collapse

Summary

The SendMessage tool's documentation states "Refer to teammates by name, never by UUID." This guidance is accurate for concurrent multi-agent coordination, but it does not cover the resume-after-completion pattern, where the name registry has already deregistered the agent.

Observed behavior

After a background sub-agent completes, attempting SendMessage to: "<agent-name>" returns:

{"success":false,"message":"No agent named '<name>' is currently addressable. Spawn a new one or use the agent ID."}

Retrying with the agent's UUID (e.g., SendMessage to: "<agentId from the Agent tool's spawn response>") succeeds and resumes the prior session with full context intact.

Observed deterministically across 20+ post-completion SendMessage attempts in a single session (5 background agents x 4 multi-round resume cycles, every single name-based call failed, every single UUID-based call succeeded).

Expected vs actual

  • Docs say: refer to teammates by name
  • Actual: name is only valid while the agent is active. Post-completion, only UUID resolves.

Proposed improvements (either or both)

  1. Documentation: extend the SendMessage tool description to note that name-based addressing applies only to currently-active agents, and that UUID (agentId from the Agent tool's spawn response) is required to resume completed agents.
  2. Behavior: keep the name registry valid for a configurable grace period after agent completion, so the same identifier works for both active coordination and resume patterns.

Repro

  1. Spawn a background agent: Agent(... name="worker-1", run_in_background=true)
  2. Wait for completion notification
  3. Try SendMessage to: "worker-1" -> fails with the message above
  4. Try SendMessage to: "<agentId from spawn response>" -> succeeds, resumes session with prior context

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix docs(sendmessage): clarify name registry semantics for completed agents