Channels: notifications/claude/channel delivered after a tool-only turn lands in the prompt buffer instead of starting a new turn

What happened

When using a custom Claude Channel (via --dangerously-load-development-channels server:<name>), a notifications/claude/channel MCP notification delivered to Claude after a turn whose only output was a single tool call is rendered into the TUI's prompt buffer (❯ <inbound text> with the post-task new task? /clear to save Nk tokens hint underneath) instead of being processed as a synthetic user turn.

The user has to manually press Enter to submit, or the message sits in the buffer indefinitely. From Claude's perspective the turn never starts. From the user's perspective the bot has gone silent.

What I expected

notifications/claude/channel should always start a new turn for Claude to process, regardless of the shape of the previous turn. This is the Channels-spec contract — the channel implementer's whole job is to deliver these notifications and trust that Claude will respond.

Reproduction

Setup: a minimal MCP server implementing the claude/channel experimental capability, exposing one tool (e.g. reply) and sending periodic notifications/claude/channel notifications.

1. Start Claude Code: claude --dangerously-load-development-channels server:my-channel --dangerously-skip-permissions
2. Send a channel notification via the MCP server. Claude processes it, calls the reply tool, and ends the turn.
3. Wait until the TUI shows the post-task hint (new task? /clear to save Nk tokens) — i.e., Claude is idle in the prompt input state.
4. Send a second channel notification.

Observed: the notification's text appears in the prompt buffer prefixed with ❯. No new turn fires. The MCP server gets no response.

Expected: Claude immediately starts a new turn processing the notification, regardless of the idle-state UI.

Failure mode shape

The problem is not present when the previous turn included other tools (Bash, Read, Edit, Write). Only when the previous turn's outputs were exclusively mcp__<server>__<tool> calls — the kind of turn a chat-like channel produces by design (the bot reads the message and replies via the channel's send tool, nothing else).

In practice this affects most "polite" turns the bot can produce: any short Q&A where Claude just answers via the reply tool without needing to read code or run commands.

Workaround in user-land

Adding a no-op Bash call at the end of every reply-only turn (e.g., echo "turn complete") appears to mask the issue, suggesting it's the "tool-call shape" that the TUI's turn-completion path is sensitive to.

That workaround is undesirable because it adds spurious tool-call cruft to every channel-bot interaction and depends on Claude reliably following an instruction that's only there to paper over a TUI bug.

Environment

• Claude Code version: 2.1.145
• OS: macOS 26.4.1
• Channel: custom MCP server using @modelcontextprotocol/sdk 1.x, Bun runtime
• Reproduces consistently across multiple custom channels

Why this matters

Channel-based deployments are inherently low-latency conversational — the user expects every Slack/Discord/etc. message to start a fresh turn. When a reply-only turn poisons the next inbound, the bot appears to randomly stop responding. The user has to manually attach to the underlying tmux/terminal session and press Enter to unstick it — which defeats the point of running an autonomous channel-based agent.

Possibly related

claude/channel is in research preview, so this may be a known sharp edge. Filing in case it isn't.

---