[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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.

2. 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.

3. 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.

2. 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.

3. 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

```shell

```

### 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_

Start by reproducing the intermittent behavior with Claude Desktop on Windows and the configured shell and filesystem MCP servers. Correlate mcp.log, mcp-server-Filesystem.log, and claude.ai-web.log around tools/call, stdout, file writes, and side_channel_waiting_key_absent. Done means dispatch failures are distinguishable from successful calls and tool results and writes are accurately reported.

Escrito por el modelo de indexación a partir del texto del issue.