Desktop cross-session send_message: renders in target transcript but never enters the agent's context when target is attended (silent drop, both directions)

Update — resolved. See the comment below. Root cause was the crossSessionInbound permission gate holding inbound messages for review, not a delivery failure. The fix was identified by @NimaPirmoradian in #86629; setting "crossSessionInbound": "accept" at the user level (with a desktop engine >= 2.1.232) restored delivery in both directions here. The "attended vs idle" framing in the report below turned out to describe a symptom rather than the cause — that part should be treated as unreliable. The original text is left unchanged for reference.

---

Environment

• Claude Code Desktop on Windows 11 (win32)
• Cross-session messaging via the built-in session-management MCP (mcp__ccd_session_mgmt__send_message)
• Three long-running local sessions collaborating across two repos over one working day (heavy message volume, ~15+ sends)

Summary

When the target session of send_message has an interactive client attached (the user is actively using that window), the message:

1. renders as a message bubble in the target conversation's UI (the user sees it), but
2. never triggers an agent turn, and
3. never enters the model's context on any subsequent turn either — including after the target's background process was recycled and resumed fresh.

The visible transcript and the model's actual context permanently diverge: the user sees messages in the conversation that the agent has never received. There is no error on the sender side — the tool returns Message sent to session … or Message queued … will be processed after the in-flight turn finishes.

Delivery to idle, unattended sessions works correctly (wake-on-send succeeded repeatedly the same day). The failure is specific to attended/busy targets.

Evidence (one day, both directions)

1. 4/4 messages lost, human-attended receiver: one session (user actively attached all day) was sent 4 messages by a peer session. All 4 rendered in its window; none ever appeared in the agent's context on any later turn. The agent only learned their content via list_events on the peer's transcript and via files on disk. A process recycle + fresh resume did not backfill them.
2. 3 queued messages silently dropped: a session in a second repo reported that three messages queued behind its in-flight turn (sender got "will be processed after the in-flight turn finishes") were never processed — it first saw the content when the user pasted a screenshot.
3. Agent-to-agent work order lost the same way: a dispatch message sent while the target was running never reached it; the target later reported "0/4 items — the order message never arrived this turn; the user's verbal prompt is how I got it."
4. Control case: sends to the same sessions while idle/unattended woke them and were processed normally, multiple times, same day.

Expected

Either trigger a turn on delivery, or include pending cross-session messages in the context of the next (user-initiated) turn. At minimum, the UI should not render a message into the transcript that the model will never see — the rendered transcript should be truthful about what the agent knows.

Actual

Bubble renders; agent never receives it; sender gets a success/queued result; queued messages can be silently dropped when the in-flight turn ends.

Impact

Users reasonably assume the agent has read whatever is visible in its own conversation window. Multi-session workflows silently stall on "waiting for a reply that the peer never saw". Current workaround: treat messages as unreliable pings, put all real content in repo files, and have the human verbally prompt the attended session — workable, but the transcript/context divergence is actively misleading.

Possibly related lifecycle observation (same day)

Long-lived session processes are recycled between turns; senders then get "The session stopped responding. Send your message again to resume with a fresh process." Resume itself works (no context loss), but combined with the silent-drop behavior above it makes cross-session delivery feel randomly broken.

🤖 Filed with Claude Code on the user's behalf.