claude-code - 💡(How to fix) Fix Channel notifications (notifications/claude/channel) buffered instead of injected when agent is idle

Summary

Claude Code agents running an MCP server that emits notifications/claude/channel (the experimental claude/channel capability used by long-running pub/sub plugins) behave correctly while a conversation turn is in flight, but appear to buffer notifications without injecting them into the model's context when the agent is idle at the prompt (no active turn). The reliable workaround is to deliver the message as keyboard input via the TTY / screen session — at which point the agent picks up both the typed input and the previously-buffered channel notifications.

Environment

• Claude Code: current published version (multiple in our fleet, behavior consistent)
• Plugin emitting notifications/claude/channel: a Wire-broker channel plugin we maintain in-house (@agiterra/wire-tools v2.x); the MCP server declares experimental: { "claude/channel": {} } in its capabilities and pushes structured channel events via the standard notifications/claude/channel notification.
• Agents are spawned in screen sessions for headless persistence; we attach later via screen -x.

Repro

1. Spawn an agent with a long-running MCP server that exposes a channel via the experimental claude/channel capability and pushes one structured event when triggered. Verify the SSE / underlying delivery is healthy by inspecting the agent's MCP transport: the notification IS being sent to the agent's MCP process.
2. Leave the agent idle at the > prompt (no in-flight conversation turn).
3. Trigger one channel notification while the agent is idle. Observe: nothing surfaces in the agent's conversation; no <channel> tag appears in the next assistant turn.
4. Send any keyboard input via the TTY (e.g. via screen -p 0 -X stuff '.\\r'). Observe: the next turn surfaces BOTH the typed input AND the previously-buffered channel events, sometimes minutes apart, in a single batch.

We've reproduced this consistently across multiple bridge-spawned agents in headless screen sessions. The same setup processes channel notifications fine when an agent is mid-turn (events arrive interleaved as expected).

Expected

Channel notifications should be injected into the agent's context as they arrive, regardless of whether a conversation turn is in flight — equivalent to an unsolicited user message in this respect. Today, the only way to flush them is to send something else.

Workaround in production

Our orchestrator falls back to delivering IPC messages as TTY input (screen -X stuff) when the recipient is idle, because the channel-notification path can sit indefinitely. This works but is a layering violation and adds latency / fragility to our orchestrator-to-engineer messaging.

Suspected mechanism

It feels like CC's notification handler queues notifications during idle and flushes them only when an in-flight turn starts or completes. If that's accurate, the fix is to treat an inbound channel notification as a trigger that starts a new turn (or wakes the queue) rather than relying on existing turn boundaries.

Why we care

We use Wire-broker channels for ephemeral / coaching messaging between persistent orchestrator agents and short-lived engineer agents. When engineers go idle (which they do as soon as a task completes), the orchestrator's nudges silently buffer until something else wakes them. We've worked around it with TTY-stuff for now but the clean fix is on the CC side.

Happy to provide a minimal repro plugin if it would help. We can also share traces of the MCP stderr where the server logs the notification being sent at time T and the agent logs the same event being processed at time T + N minutes (where N = time-to-next-typed-input).