Cross-session message delivered to transcript but receiving session never processes it

Environment

• Claude Code version: 2.1.215
• OS: Windows 11 Pro (native, PowerShell), not WSL2
• Feature used: cross-session messaging via the session-manager tool exposed to Claude (send_message / list_events / list_sessions — the same feature surfaced in the UI as messaging between open Claude Code sessions)

Summary

A message sent from one session to another is written into the target session's transcript, and the target session's status flips to "running" (as if it were about to process the incoming turn), but the target session never actually generates an assistant turn in response — it never "reads" the message.

Steps to reproduce

1. Open two Claude Code sessions locally (e.g. two tabs/windows in the session manager). Call them Session A (sender) and Session B (receiver). Session B was idle (isRunning: false).
2. From Session A, send a message to Session B via the cross-session messaging tool, e.g.: send_message(session_id=<B>, message="Hola, te ha llegado el mensaje?").
3. The tool call succeeds and reports the message was sent.
4. From Session A, list Session B's recent events/transcript.

Expected

Session B receives the message as a new turn, Claude in Session B starts a new turn processing it, and (per the feature's own design) generates an assistant reply — the same way an interactive session responds to a new user message.

Actual

• The message appears correctly in Session B's transcript as a user turn wrapped in a <cross-session-message from="..." name="..."> tag.
• Session B's status changes from isRunning: false to "running" immediately after the message is delivered.
• No assistant turn is ever produced in response. Two consecutive reads of Session B's transcript, several seconds apart, show the exact same last event (the incoming user message, with no reply after it).
• This reproduced consistently in "todo tipo de sesiones" per the reporting user's own repeated testing before this specific repro (i.e. not isolated to one session or one type of session).

Notes

• This is not the crossSessionInbound settings gate (accept/hold/refuse in settings.json) — that setting was already reviewed and doesn't explain this; the message is being delivered into the transcript (not held/refused), the receiving session just never actually processes the delivered turn.
• Not an "unattended session" case (scheduled-task run / remote-dispatched session) — Session B was a normal local interactive session that was simply idle at the time.
• This effectively breaks a common workflow: an orchestrator session coordinating multiple parallel worker sessions (e.g. across git worktrees) relies on being notified when a worker session finishes/reports back via cross-session messages; if the receiving session never processes the delivered message, the orchestrator never gets acted upon.