claude-code - 💡(How to fix) Fix [FEATURE] streamingBehavior on notifications/claude/channel for MCP-side delivery timing

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Channel notifications (notifications/claude/channel) land in the session whenever the runtime gets round to them. The MCP server has no way to say "deliver this at the next tool boundary" vs "wait until the agent's idle" vs "whenever, it's just FYI". One lane for everything.

The TUI-input side has plenty of asks for the same delivery-timing knob (#30492, #62856, #63190, #50246). The channel protocol itself still has nothing.

Hitting this in agent-comms, a cross-harness messaging mesh. When a remote agent DMs a Claude Code session via the channel bridge, the message just disappears into the queue with no timing semantics. No way to say "this is urgent, the receiver should react at the next decision point" vs "this is just an FYI, deliver when convenient".

Proposed Solution

Optional streamingBehavior on the notification params:

{
  "method": "notifications/claude/channel",
  "params": {
    "content": "...",
    "meta": {},
    "streamingBehavior": "steer" | "followUp" | "info"
  }
}

• steer: deliver after the current tool call but before the next LLM call. Mid-task redirect without aborting.
• followUp: queue until the agent is fully idle, then inject as the next user turn.
• info: inject whenever convenient (default, matches current behaviour).

Capability declaration in the server's experimental block so the runtime knows the sender understands what it's asking for:

"experimental": { "claude/channel": { "streamingBehavior": true } }

If #30492 lands, this is the same plumbing exposed to MCP servers instead of the TUI input box. Same queue, same boundary logic, different surface.

Alternative Solutions

Buffer in the MCP server and drain on the next tools/call (pull instead of push). Fine for info. Useless for steer because the agent might not call the tool for ages, if at all.

Wrap the Agent SDK with streamInput() and yield at the right times. Only works if you're hosting the SDK yourself, not for an MCP server pushing into a vanilla CLI session.

Prefix the content with ⚡ STEER: and hope the model treats it differently. Pollutes the content, unreliable, and the timing's still wrong.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

Cross-harness multi-agent setup. Agent A DMs agent B (Claude Code) via the channel bridge. If B's halfway through a multi-file refactor, the DM might land mid-edit, between turns, or get bundled into the next prompt cycle that doesn't happen for ages. Sender has no way to express "this matters now, react at the next decision point" vs "deliver when you're done".

Same problem for CI pings, room broadcasts, anything else a channel server wants to push with intent.

Additional Context

Related but not duplicates (all target TUI-typed input, not the channel protocol):

• #30492: TUI steering for user-typed messages. Same underlying runtime mechanism, different surface.
• #62856: Send-time interrupt vs queue in the TUI.
• #63190: Deferred messages from the TUI.
• #50246: Message queue mode.

Separate channel delivery bugs worth fixing first: #59240, #58018, #36477.