[BUG] send_message` (ccd_session_mgmt) renders in the recipient's UI but is never injected — regression between app 2.1.222 and 2.1.227

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?

Title: send_message (ccd_session_mgmt) renders in the recipient's UI but is never injected — regression between app 2.1.222 and 2.1.227

Environment

• Claude Desktop app (Windows), CCD agent sessions, MCP server ccd_session_mgmt, tool send_message
• Windows Server 2025 Datacenter 10.0.26100 — single machine, all sessions same user, same working directory
• Broken on 2.1.227 and 2.1.229. Last working version: 2.1.222
• Observed 2026-08-13, 2026-08-14; re-tested 2026-08-16

Summary

send_message returns a success acknowledgement (Message sent to session …), the message renders correctly in the recipient's window as an inbound card, and it is never injected as a turn. It never reaches the recipient's transcript and the recipient's model never sees it. No error surfaces on either side.

Additionally, an idle recipient is blocked for ~15 min 55 s (measured twice, four seconds apart). The block is bounded and self-resolving; no interrupt is needed; typed input is queued behind it and processed normally afterwards. A busy recipient shows no visible block. In neither case is the message injected, and there is no late delivery.

This is a regression — here is the version window

The feature worked at scale and then stopped. We measured this by the fingerprint a successful delivery leaves in the recipient's transcript: a user record wrapped in <cross-session-message from="local_…" name="<sender title>" encoded="1">.

Scanned 810 transcript files under ~/.claude/projects/<project>/:

| | |
| :-- | :-- |
| Deliveries found | 630 |
| First | 2026-07-21 17:43:35 — app 2.1.215 |
| Last | 2026-08-11 21:36:15 — app 2.1.222 |
| Deliveries since | 0, across 26+ sends |

| App version | first record | last record | deliveries |
| :-- | :-- | :-- | --: |
| 2.1.221 | 2026-08-05 07:19 | 2026-08-07 15:23 | yes |
| 2.1.222 | 2026-08-07 14:13 | 2026-08-12 07:47 | yes — last one |
| 2.1.227 | 2026-08-12 07:48 | 2026-08-14 12:08 | 0 |
| 2.1.229 | 2026-08-14 11:46 | current | 0 |

The last delivery precedes the 2.1.222 → 2.1.227 boundary by ~10 hours (overnight — we do not claim anything was attempted in that gap). What we do claim: 26+ sends under 2.1.227/2.1.229, none arrived.

The same release demonstrably changed this feature

Sending to a scheduled-task session is now refused explicitly:

Session <id> is unattended (a scheduled-task run or dispatched session); messages can't be delivered there.

That restriction is new. It previously worked: two deliveries to unattended sessions on 2026-08-05 under app 2.1.221, carrying the same <cross-session-message> marker. The restriction is now also stated in the tool's own description.

We are not claiming this refusal is the bug — it looks deliberate and may be correct. We are pointing out that the same release window contains an intentional change to send_message's delivery path.

Reproduction (2026-08-16, app 2.1.229)

1. From an attended agent session, send_message to another attended session, body containing a unique token.
2. Observe: acknowledgement Message sent to session …; the card renders in the recipient's window; the recipient's spinner starts.
3. Search all transcripts for a user record containing both the <cross-session-message> marker and the token.

Result: two sends (one idle recipient, one started minutes earlier) — zero deliveries. Re-checked every 30 s for 4.5 minutes: still zero. Screenshots of both recipient windows show the card rendered and the session spinning, confirming the split between UI and turn injection on the current version.

How to avoid mismeasuring this (we got it wrong twice)

• Do not use the acknowledgement. sent/queued is returned in the broken state too.
• Do not use lastActivityAt or "session is running". The recipient wakes and blocks without receiving anything.
• Do not grep for the token alone. A transcript search finds the sender's own quotation of the token in its own tool call. Require the <cross-session-message> marker as well.
• Negative control: the same search finds 1616 occurrences of the marker across our corpus. If a search returns nothing at all, the search is broken, not the channel.

Impact

Agent-to-agent coordination is silently lost. Because the sender receives a success acknowledgement and the human sees the message rendered in the recipient's window, both parties reasonably believe it arrived — only the recipient's model never sees it. Each send additionally costs an idle recipient ~16 minutes. We have moved all inter-session coordination to a file/git channel as a workaround.

What we are not claiming

Causation. We did not inspect the client. Something else may have changed at the same time. But there is exactly one changed variable we can observe — a version jump — and that release verifiably touched this feature.

Suggested fix, in order of value to us

1. Restore turn injection for attended → attended sends.
2. If a send cannot be delivered, fail loudly to the sender instead of acknowledging success.
3. Do not block the recipient while a message is being processed.

What Should Happen?

No Agent-to-agent coordination is silently lost.

Error Messages/Logs

Steps to Reproduce

Title: send_message (ccd_session_mgmt) renders in the recipient's UI but is never injected — regression between app 2.1.222 and 2.1.227

Environment

• Claude Desktop app (Windows), CCD agent sessions, MCP server ccd_session_mgmt, tool send_message
• Windows Server 2025 Datacenter 10.0.26100 — single machine, all sessions same user, same working directory
• Broken on 2.1.227 and 2.1.229. Last working version: 2.1.222
• Observed 2026-08-13, 2026-08-14; re-tested 2026-08-16

Summary

send_message returns a success acknowledgement (Message sent to session …), the message renders correctly in the recipient's window as an inbound card, and it is never injected as a turn. It never reaches the recipient's transcript and the recipient's model never sees it. No error surfaces on either side.

Additionally, an idle recipient is blocked for ~15 min 55 s (measured twice, four seconds apart). The block is bounded and self-resolving; no interrupt is needed; typed input is queued behind it and processed normally afterwards. A busy recipient shows no visible block. In neither case is the message injected, and there is no late delivery.

This is a regression — here is the version window

The feature worked at scale and then stopped. We measured this by the fingerprint a successful delivery leaves in the recipient's transcript: a user record wrapped in <cross-session-message from="local_…" name="<sender title>" encoded="1">.

Scanned 810 transcript files under ~/.claude/projects/<project>/:

| | |
| :-- | :-- |
| Deliveries found | 630 |
| First | 2026-07-21 17:43:35 — app 2.1.215 |
| Last | 2026-08-11 21:36:15 — app 2.1.222 |
| Deliveries since | 0, across 26+ sends |

| App version | first record | last record | deliveries |
| :-- | :-- | :-- | --: |
| 2.1.221 | 2026-08-05 07:19 | 2026-08-07 15:23 | yes |
| 2.1.222 | 2026-08-07 14:13 | 2026-08-12 07:47 | yes — last one |
| 2.1.227 | 2026-08-12 07:48 | 2026-08-14 12:08 | 0 |
| 2.1.229 | 2026-08-14 11:46 | current | 0 |

The last delivery precedes the 2.1.222 → 2.1.227 boundary by ~10 hours (overnight — we do not claim anything was attempted in that gap). What we do claim: 26+ sends under 2.1.227/2.1.229, none arrived.

The same release demonstrably changed this feature

Sending to a scheduled-task session is now refused explicitly:

Session <id> is unattended (a scheduled-task run or dispatched session); messages can't be delivered there.

That restriction is new. It previously worked: two deliveries to unattended sessions on 2026-08-05 under app 2.1.221, carrying the same <cross-session-message> marker. The restriction is now also stated in the tool's own description.

We are not claiming this refusal is the bug — it looks deliberate and may be correct. We are pointing out that the same release window contains an intentional change to send_message's delivery path.

Reproduction (2026-08-16, app 2.1.229)

1. From an attended agent session, send_message to another attended session, body containing a unique token.
2. Observe: acknowledgement Message sent to session …; the card renders in the recipient's window; the recipient's spinner starts.
3. Search all transcripts for a user record containing both the <cross-session-message> marker and the token.

Result: two sends (one idle recipient, one started minutes earlier) — zero deliveries. Re-checked every 30 s for 4.5 minutes: still zero. Screenshots of both recipient windows show the card rendered and the session spinning, confirming the split between UI and turn injection on the current version.

How to avoid mismeasuring this (we got it wrong twice)

• Do not use the acknowledgement. sent/queued is returned in the broken state too.
• Do not use lastActivityAt or "session is running". The recipient wakes and blocks without receiving anything.
• Do not grep for the token alone. A transcript search finds the sender's own quotation of the token in its own tool call. Require the <cross-session-message> marker as well.
• Negative control: the same search finds 1616 occurrences of the marker across our corpus. If a search returns nothing at all, the search is broken, not the channel.

Impact

Agent-to-agent coordination is silently lost. Because the sender receives a success acknowledgement and the human sees the message rendered in the recipient's window, both parties reasonably believe it arrived — only the recipient's model never sees it. Each send additionally costs an idle recipient ~16 minutes. We have moved all inter-session coordination to a file/git channel as a workaround.

What we are not claiming

Causation. We did not inspect the client. Something else may have changed at the same time. But there is exactly one changed variable we can observe — a version jump — and that release verifiably touched this feature.

Suggested fix, in order of value to us

1. Restore turn injection for attended → attended sends.
2. If a send cannot be delivered, fail loudly to the sender instead of acknowledging success.
3. Do not block the recipient while a message is being processed.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.227

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_