[BUG] Claude Desktop MSIX stderr swallowing

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?

Summary

Claude Desktop v1.8555.2.0 (Microsoft Store / MSIX build) does not capture or
surface stderr output from spawned MCP server child processes. This makes MCP
server crashes effectively undiagnosable from inside Claude Desktop — the only
visible log entry is "Server transport closed unexpectedly", with no detail
about what actually happened in the child process.

Reproduction

1. Install @modelcontextprotocol/server-filesystem as a Claude Desktop Extension.
2. In Extensions Settings, set allowed_directories to include at least one

directory that does not exist on disk.

1. Restart Claude Desktop and observe %APPDATA%\Claude\logs\mcp.log and

%APPDATA%\Claude\logs\mcp-server-Filesystem.log.

Observed in log:
[Filesystem] Initializing server...
[Filesystem] Using built-in Node.js for MCP server: Filesystem
[Filesystem] Server started and connected successfully
[Filesystem] Message from client: {"method":"initialize",...}
[Filesystem] Server transport closed
[Filesystem] Server transport closed unexpectedly, this is likely due to the
process exiting early. If you are developing this MCP server you can add
output to stderr ... and it will appear in this log.
[Filesystem] Server disconnected.

Note the log explicitly tells the user console.error output will appear in the
log. It doesn't, on the MSIX build.

1. Run the same dist/index.js manually outside Claude Desktop with the same args:

node "C:\Users\chris\AppData\Roaming\Claude\Claude Extensions\ant.dir.ant.anthropic.filesystem\dist\index.js" "C:\exists" "C:\does-not-exist"

Observed in console:
Error accessing directory C:\does-not-exist: Error: ENOENT: no such file or directory,
stat 'C:\does-not-exist'
at async Object.stat (node:internal/fs/promises:1038:18)
...

The server does write a clear stderr message — Claude Desktop just isn't
capturing/logging it.

I also confirmed that the working server's startup banner "Secure MCP Filesystem
Server running on stdio" (also written to stderr) never appears in mcp.log,
even on successful runs. So stderr capture appears to be missing entirely on this
build, not just on crashes.

Impact

Every MCP server startup failure on the Store build looks identical from the
user's perspective: "transport closed unexpectedly". Users cannot self-diagnose,
and support volume goes up correspondingly. In my case this turned a five-second
fix (remove a stale entry from allowed_directories) into an hour-plus debugging
session.

Expected behavior

The spawned child process's stderr should be piped to mcp.log and/or the
per-server log file (mcp-server-<Name>.log), prefixed and timestamped the
same way other log lines are. The note in the existing log message
("If you are developing this MCP server you can add output to stderr ... and
it will appear in this log") explicitly promises this behavior; it's only
broken on the MSIX build.

Environment

• Claude Desktop: v1.8555.2.0, Microsoft Store / MSIX install
• Install path: C:\Program Files\WindowsApps\Claude_1.8555.2.0_x64__pzs8sxrjxfjjc\app\
• Confirmed via stack trace in mcp-server-Filesystem.log
• OS: Windows 11 Pro, Canary channel
• Config: isUsingBuiltInNodeForMcp: true
• MCP server: @modelcontextprotocol/server-filesystem v0.2.0

(secure-filesystem-server)

Notes

• The standalone .exe installer build of Claude Desktop may or may not have

the same issue — I have not tested it. If stderr capture works on the
standalone build but not the MSIX one, the root cause is almost certainly
the MSIX/AppContainer's handling of stdio: 'pipe' from Electron's
child_process.spawn().

• Related upstream bug in the MCP server itself (Promise.all rejection on

missing dir) filed at https://github.com/modelcontextprotocol/servers/issues/[your-issue#]
— fixing it on the server side would prevent this specific failure
from being silent, but the stderr-swallow bug applies to every MCP server,
not just filesystem.

What Should Happen?

The MCP File System connector should have loaded but creashes silently and errors pops up in the Claude Desktop UI.

Error Messages/Logs

None

Steps to Reproduce

See body text

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.8555.2.0 — MSIX/Store build, package Claude_1.8555.2.0_x64__pzs8sxrjxfjjc

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_