[BUG] Windows: MCP shell/filesystem tool calls intermittently not dispatched or silently not executed - stdout returns null on success, writes report success but never land, web-to-Desktop bridge logs side_channel_waiting_key_absent

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?

TITLE (after the [BUG] prefix the template adds):
Windows: MCP shell/filesystem tool calls intermittently not dispatched or silently not executed - stdout returns null on success, writes report success but never land, web-to-Desktop bridge logs side_channel_waiting_key_absent

=== What's Wrong? ===
On Claude Desktop for Windows, local MCP servers (shell via shell:run_command, filesystem) intermittently degrade in three related ways, recurring over multiple weeks:

1. shell:run_command returns null stdout even when the command executes successfully (verified: the command's file-side effects land on disk and are readable via the filesystem MCP). Other sessions, the same null-stdout signature appears when the command did NOT execute at all (no file side effects) - so the client gives an identical "null" for both success and total dispatch failure, making the two indistinguishable from the user side.

1. filesystem MCP write tools report success but the file is not present at the target path when read back moments later by the shell or by the filesystem MCP itself (same session, same path; e.g. write_file succeeds, an immediate str_replace on the identical path returns File not found, and a second write_file to the same path then succeeds). The filesystem and shell servers also intermittently see different volume views of the same directory tree.

1. During the 2026-07-21/22 regression window, filesystem tools/call was never dispatched at all: mcp.log and mcp-server-Filesystem.log show a clean handshake (initialize -> notifications/initialized -> tools/list answered) with zero tools/call entries afterward, while claude.ai-web.log logged repeated side_channel_waiting_key_absent errors - i.e., calls issued from a claude.ai web conversation died in the web-to-Desktop bridge before reaching the Desktop client. Deleting the Claude for Chrome extension (installed days earlier) and restarting changed nothing at the time.

The servers themselves are healthy throughout: when dispatch works, calls answer in milliseconds; server logs show no errors. Session restart sometimes clears the null-stdout state, sometimes does not. Claude Code CLI on the same machine is unaffected.

This reproduces the dispatch-failure family in #80002 / #80094 / #66726, on Windows, with the additional web-bridge signature (side_channel_waiting_key_absent) and the silent write-success failure mode.

=== What Should Happen? ===
tools/call issued from a conversation should be delivered to the local MCP server, and the result (including stdout) returned to the model. If dispatch cannot deliver, the call should fail fast with a distinct, logged error - not return null on success AND on non-execution identically, and not report a write as successful when

What Should Happen?

TITLE (after the [BUG] prefix the template adds):
Windows: MCP shell/filesystem tool calls intermittently not dispatched or silently not executed - stdout returns null on success, writes report success but never land, web-to-Desktop bridge logs side_channel_waiting_key_absent

=== What's Wrong? ===
On Claude Desktop for Windows, local MCP servers (shell via shell:run_command, filesystem) intermittently degrade in three related ways, recurring over multiple weeks:

1. shell:run_command returns null stdout even when the command executes successfully (verified: the command's file-side effects land on disk and are readable via the filesystem MCP). Other sessions, the same null-stdout signature appears when the command did NOT execute at all (no file side effects) - so the client gives an identical "null" for both success and total dispatch failure, making the two indistinguishable from the user side.

1. filesystem MCP write tools report success but the file is not present at the target path when read back moments later by the shell or by the filesystem MCP itself (same session, same path; e.g. write_file succeeds, an immediate str_replace on the identical path returns File not found, and a second write_file to the same path then succeeds). The filesystem and shell servers also intermittently see different volume views of the same directory tree.

1. During the 2026-07-21/22 regression window, filesystem tools/call was never dispatched at all: mcp.log and mcp-server-Filesystem.log show a clean handshake (initialize -> notifications/initialized -> tools/list answered) with zero tools/call entries afterward, while claude.ai-web.log logged repeated side_channel_waiting_key_absent errors - i.e., calls issued from a claude.ai web conversation died in the web-to-Desktop bridge before reaching the Desktop client. Deleting the Claude for Chrome extension (installed days earlier) and restarting changed nothing at the time.

The servers themselves are healthy throughout: when dispatch works, calls answer in milliseconds; server logs show no errors. Session restart sometimes clears the null-stdout state, sometimes does not. Claude Code CLI on the same machine is unaffected.

This reproduces the dispatch-failure family in #80002 / #80094 / #66726, on Windows, with the additional web-bridge signature (side_channel_waiting_key_absent) and the silent write-success failure mode.

=== What Should Happen? ===
tools/call issued from a conversation should be delivered to the local MCP server, and the result (including stdout) returned to the model. If dispatch cannot deliver, the call should fail fast with a distinct, logged error - not return null on success AND on non-execution identically, and not report a write as successful when

Error Messages/Logs

Steps to Reproduce

Intermittent; no deterministic trigger found. Highest-frequency reproduction on this machine:

1. Claude Desktop on Windows with shell + filesystem MCP servers configured (npm @modelcontextprotocol/server-filesystem; shell server), used from claude.ai web conversations in a Project.
2. Run a session with repeated shell:run_command calls (python scripts against local files/SQLite DB).
3. Observe stdout returning null on calls whose side effects verifiably landed (Signature A - see logs section) - near-constant.
4. Continue across sessions/days; eventually a session exhibits Signature B (no execution at all) - a bare echo test returns null and probe writes do not land on disk. Full tray-exit + relaunch sometimes clears it, sometimes not.
5. The 7/21-7/22 auto-update window produced Signature C (tools/call never dispatched, clean handshake in logs, side_channel_waiting_key_absent in claude.ai-web.log) on every new conversation until the regression passed.

Workaround in production use: never trust stdout; write all output to a file and read it back via filesystem MCP; treat write-success as unverified until read back.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

n/a

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_