原文（日本語に翻訳）
再スポーンされたエージェントが以前のエージェントの名前を再利用した際にSendMessageが黙って誤ったあて先にメッセージを送ってしまう問題を修正。ツールが名前の不一致を検出し、呼び出し元に送信先の指定し直しを求めるようになった。
原文（英語）
Fixed SendMessage silently misrouting when a re-spawned agent reuses a previous agent's name — the tool now detects the mismatch and asks the caller to retarget
概要
SendMessageは、サブエージェントを名前やエージェントIDをtoフィールドに指定して再開（resume）するために使われるツールです。バックグラウンドで動いていたエージェントが停止後に再スポーンされ、以前と同じ名前を再利用した場合、修正前はSendMessageがその名前の履歴を追跡していなかったため、送信者が意図した「以前のエージェント」ではなく「名前を引き継いだ新しいエージェント」に黙ってメッセージが届いてしまうことがありました。v2.1.199では、会話内で一度到達した名前が別のエージェントに切り替わったことを検出し、誤送信せずにエラーを返してあて先の指定し直しを促すようになりました。
基本的な使い方
修正前:
1. 名前「researcher」のサブエージェントを起動し、作業を依頼
2. そのエージェントが停止し、別のバックグラウンドエージェントが
同じ「researcher」という名前で再スポーンされる
3. SendMessage({ to: "researcher", ... }) を実行
→ ❌ 意図せず新しい「researcher」に届いてしまう（誤配信）修正後（v2.1.199）:
1. 名前「researcher」のサブエージェントを起動し、作業を依頼
2. そのエージェントが停止し、別のバックグラウンドエージェントが
同じ「researcher」という名前で再スポーンされる
3. SendMessage({ to: "researcher", ... }) を実行
→ ✅ 名前が別のエージェントに切り替わったことを検出し送信を拒否
→ エラーで「researcher」が現在どのエージェントを指しているか報告
4. 以前のエージェントに届けたい場合は、スポーン結果に含まれる
エージェントID宛てに送信し直す実践例
バックグラウンドサブエージェントを名前で再開しようとする場合
長時間セッションで同名のバックグラウンドエージェントが何度も起動・停止を繰り返すワークフローでは、以前の名前が別プロセスに再割り当てされていることに気づかずSendMessageで作業を依頼してしまうリスクがありました。v2.1.199以降は、名前が指すエージェントが変わっていればエラーで知らせてくれるため、誤って無関係なエージェントに指示を出してしまう事故を防げます。
エージェントIDでの確実な再開
以前のエージェントがまだ動作中で、名前が別のエージェントに奪われている場合でも、そのエージェントのスポーン結果に含まれるエージェントIDをtoに指定すれば、名前の衝突とは無関係に正しい相手へメッセージを届けられます。
/clearをまたいだ長時間セッション
この名前重複チェックは現在の会話スコープに限定されており、/clearを実行するとリセットされます。頻繁に/clearを挟みながら多数のバックグラウンドエージェントを使い回す場合は、チェックがリセットされる点を踏まえてエージェントの状態を確認する習慣を持つとよいでしょう。
注意点
- このチェックは現在の会話内に限定されており、
/clearを実行するとリセットされます。 SendMessageはagent teams機能が無効でも、サブエージェントの再開のために利用できます。agent teams固有のプロトコルメッセージ（shutdown_requestやplan_approval_responseなど）だけがagent teamsの有効化を必要とします。- 停止中のサブエージェントが
SendMessageを受け取ると、新たにAgentを呼び出さなくてもバックグラウンドで自動的に再開されます。