Preflight Checklist

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

What's Wrong?

On the desktop app's Code mode (local & remote), every session crashes ~1s after spawn with Claude Code process exited with code 15, whenever a global stdio MCP server is configured in ~/.claude.json "mcpServers". Removing that one server fixes Code mode immediately.

The binary starts up cleanly, then silently process.exit(15) during init — nothing on stderr, no stack trace. Chat mode, Cowork mode and the standalone claude CLI are all unaffected. Began after the binary updated to 2.1.149 (which shipped sandbox / PowerShell-permission changes).

What Should Happen?

If a configured stdio MCP server fails to start, the binary should disable just that one server and continue (as it did before 2.1.149) — not abort the whole process with exit 15. Code mode should start normally.

Error Messages/Logs

# desktop host log (main.log)
[CCD] [replaceRemoteMcpServers] Calling SDK with 9 total servers
[error] Failed to toggle remote control for local_<id>: Claude Code process exited with code 15
[error] Session local_<id> query error: Claude Code process exited with code 15
    at getProcessExitError (...index.js)
    at ChildProcess._handle.onexit (node:internal/child_process:295:12)
[CCD CycleHealth] unhealthy cycle for local_<id> (1s, hadFirstResponse=false, reason=no_response)

# binary side (wrapper that tees stdio + injects --debug-file)
stderr: EMPTY (silent exit, not a throw)
--debug-file: clean startup through 'Watching for changes in setting files', then stops; no [FATAL]
stdout: 0 bytes (never emits first stream-json response -> host reports no_response)
last stdout before exit = SessionStart hook (exit_code:0, success), then exit 15

Steps to Reproduce

Repro:

1. Add a global stdio MCP server under "mcpServers" in ~/.claude.json (mine: a Python stdio MCP on a secondary drive with spaces in the path, Python 3.14).
2. Open a Code session in the desktop app and send any message (e.g. "hi").
3. Result: "Claude Code process exited with code 15", reason=no_response, within ~1s.
4. Remove that mcpServers entry and Code mode works again.

Bisection (binary run directly OUTSIDE the desktop app, with the captured argv/env/stdin):

• full captured argv => exit 15 (reproduces with no desktop app involved at all)
• remove ONLY the --mcp-config stdio server => exit 0 (binary starts, emits init, then waits normally)

So the configured stdio MCP server is the necessary and sufficient trigger. The MCP server itself starts fine and speaks MCP when launched directly; the binary still exits 15.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.148 (last pre-2.1.149)

Claude Code Version

2.1.156 (Claude Code) - bundled in desktop app 1.9659.2 (MSIX); also repro'd on 2.1.149 / 2.1.152

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Why other modes are fine: the CLI uses a different startup path; Cowork does NOT merge the user's global ~/.claude.json "mcpServers" into the session, so the offending server is never spawned — same binary, only Code mode passes it via --mcp-config.

Likely mechanism (inferred, since the binary swallows the real error): a 2.1.149+ regression where a configured stdio MCP server that can't be brought up at startup now aborts the whole process (exit 15) instead of being disabled and skipped. My MCP command is on a non-system drive (B:) with spaces in the path plus an external Python venv, which may trip the new spawn sandbox / permission logic shipped in 2.1.149.

Ruled out (each with counter-evidence): the offending config lives in the ~/.claude.json FILE (not the .claude/ folder — moving the folder doesn't remove it); full MSIX uninstall+reinstall; binary-version swap; proxy on/off; model/effort.

Possibly related: #62051, #56679, #62028. I have a transparent stdio-interception wrapper + the injected --debug-file log + the exit-0/exit-15 bisection captures and can share them (sanitized) if useful.

(Note: "Terminal/Shell = PowerShell" above refers to where the standalone repro was run; the actual crash is in the desktop app's Code mode, not a terminal.)