MCP channel notifications dropped while agent is mid-turn

Problem

When using an MCP channel plugin (e.g., Telegram), inbound notifications sent via mcp.notification() are dropped or silently queued if the agent is mid-turn (executing tool calls, generating a response). The user has to wait for the agent's full turn to complete before sending a follow-up message, otherwise the message never appears in the conversation.

Expected behavior

Notifications arriving mid-turn should be buffered and delivered to the agent's context once the current turn completes, so no messages are lost. Ideally the agent would see them as the next input after its response.

Current behavior

Messages sent while the agent is processing tool calls (e.g., creating a calendar event, fetching a URL, then replying) are lost entirely. The MCP server fires the notification successfully — the issue is on the harness side where there's no active "waiting for input" state to receive it.

Reproduction

1. Set up a Telegram channel plugin (or any MCP server that sends notifications/claude/channel)
2. Send a message to the agent via the channel
3. While the agent is mid-response (multiple tool calls), send a second message
4. The second message never appears in the conversation

Impact

This is a significant UX issue for always-on agent setups where the user communicates entirely through a channel plugin. Users have to carefully time their messages around the agent's processing, which feels unnatural and leads to messages being silently lost.

Environment

• Claude Code CLI with MCP channel plugin (Telegram)
• macOS, always-on tmux session