[BUG] notifications/claude/channel MCP notifications silently dropped on Windows for online-mode plugins

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

## Bug

MCP channel notifications (notifications/claude/channel) are silently dropped
on Claude Code for Windows when the MCP plugin connects to a remote (non-localhost)
WebSocket server. The same plugin + same notification code works correctly on
Linux and in local mode on Windows.

## Environment

• Platform: Windows 11 (10.0.26200)
• Claude Code: native install, --dangerously-load-development-channels flag active
• Plugin: legion-chat (dual-mode MCP chat bridge)

## Reproduction

1. MCP plugin connects to a remote WebSocket server (WSS or plain WS via SSH tunnel)
2. Plugin receives a chat message from a peer
3. Plugin calls mcp.notification({ method: 'notifications/claude/channel', params: { content: '...', meta: { user, message_id, ts } } })
4. The Promise resolves (NOTIF_OK confirmed in probe file — bytes were written to stdio)
5. No <channel> tag appears in the Claude Code conversation on Windows

## Evidence

Probe file (os.tmpdir()/legion-ws-probe.txt) confirms NOTIF_OK fires for every
incoming message — the notification is sent successfully over stdio. But Claude Code
Windows never surfaces it as a <channel source="..."> tag.

What works on Windows: Same plugin in local mode (WebSocket to localhost daemon)
→ <channel> tags appear correctly.

What works on Linux: Same plugin in online mode (WSS to remote server) →
<channel> tags appear correctly (confirmed by peer Claude instance).

Tested: WSS (wss://...) and plain WS via SSH tunnel (ws://localhost:8789) both
fail the same way on Windows. The WebSocket protocol is not the cause.

## Conclusion

The mcp.notification() call succeeds (Promise resolves), but the Windows Claude
Code client silently drops notifications/claude/channel notifications that arrive
from a plugin whose WebSocket connection is remote. This appears to be a
platform-specific bug in notification routing on the Windows client.

What Should Happen?

When mcp.notification({ method: 'notifications/claude/channel', ... }) is called by an MCP plugin on any platform, Claude Code should surface the notification as a <channel source="..."> tag in the active conversation — regardless of whether the plugin's underlying WebSocket connection is local or remote.

Error Messages/Logs

No errors surface in Claude Code UI. The plugin's stdio probe file shows NOTIF_OK (the .then() on mcp.notification() resolves successfully), confirming the bytes were written to the MCP stdio transport. Claude Code silently drops the notification with no feedback

Steps to Reproduce

Steps to reproduce:

1. Write an MCP plugin that maintains a persistent WebSocket connection to a remote server (e.g. a chat relay)
2. Register it in ~/.claude.json as a stdio MCP server
3. Launch Claude Code with --dangerously-load-development-channels
4. When the plugin receives a message over the WebSocket, call:

mcp.notification({
method: 'notifications/claude/channel',
params: { content: 'hello', meta: { user: 'peer', message_id: 'abc', ts: '2026-04-08T...' } }
})

1. On Linux → <channel> tag appears in conversation ✓

On Windows → nothing appears, no error ✗

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.97

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_