[BUG] Claude Code Desktop app: all sessions crash (exit code 1) when managed-mcp.json is deployed — enterprise MCP security controls unusable

Preflight Checklist

• [x] I have searched existing issues — this extends #11910 (VS Code only) to the Desktop app
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When an enterprise managed-mcp.json file is deployed to the system-wide configuration directory (/Library/Application Support/ClaudeCode/managed-mcp.json on macOS), every Claude Code session launched from the Claude Desktop app fails immediately with exit code 1. The CLI works normally with the same file present.

This is a critical blocker for enterprise security: organizations cannot deploy centralized MCP server allowlists (the documented enterprise mechanism) without breaking the Desktop app for all users. The only workaround is to delete managed-mcp.json, which removes the enterprise MCP governance that ISO 27001 A.5.21 (ICT Supply Chain) and ISO 42001 A.6.2.11 (Third-Party Components) controls require.

Root Cause

The Desktop app's SDK always passes --strict-mcp-config when launching the Claude Code CLI subprocess. The CLI detects the enterprise managed-mcp.json and rejects the combination:

You cannot use --strict-mcp-config when an enterprise MCP config is present

This error goes to stderr, which the SDK discards (stdio: ["pipe", "pipe", "ignore"] in the spawn call), so no error message appears in any log. The Desktop app only sees exit code 1.

Relation to Prior Issues

• #11910 — Same root cause, reported for VS Code extension only. This issue confirms the Desktop app is equally affected.
• #13263 — Closed as duplicate of #11910. Reported a similar --strict-mcp-config vs enterprise config conflict.
• #30953 — Related: requests Desktop app honor managed-settings.json for all permissions.

Environment

• Claude Desktop app: v1.1.8629 (macOS, arm64)
• Claude Code CLI: v2.1.78
• OS: macOS 26.4 (Darwin 25.4.0, Apple Silicon)
• Managed settings path: /Library/Application Support/ClaudeCode/managed-mcp.json
• Deployment method: MDM (endpoint-managed)

Reproduction Steps

1. Deploy a valid managed-mcp.json to /Library/Application Support/ClaudeCode/:

``json
{
"mcpServers": {
"example": {
"type": "http",
"url": "https://example.com/mcp"
}
}
}
``

1. Open Claude Desktop app

1. Start any Claude Code session (any project directory)

1. Result: Session immediately fails. Desktop app log (~/Library/Logs/Claude/main.log) shows:

``
[error] Session <id> query error: Claude Code process exited with code 1
[info] [CCD CycleHealth] unhealthy cycle for <id> (0s, hadFirstResponse=false, reason=no_response)
``

1. Verify root cause — run the CLI directly with the same flags the SDK passes:

``bash
claude --strict-mcp-config --mcp-config '{"mcpServers":{"test":{"command":"echo","args":["hi"]}}}' 2>&1
`
Output: You cannot use --strict-mcp-config when an enterprise MCP config is present` (exit 1)

1. Fix — delete managed-mcp.json, restart Desktop app. Sessions work.

Expected Behavior

The Desktop app should start sessions normally when managed-mcp.json is deployed. The enterprise MCP config should take precedence over the SDK's --strict-mcp-config, merging or overriding as appropriate — not causing a fatal error.

Actual Behavior

Every session crashes immediately with exit code 1. The error message is only visible on stderr, which the SDK discards. No diagnostic information appears in the Desktop app logs (main.log, swift.log, etc.).

Impact

• Severity: Critical for enterprise deployments
• Scope: Affects ALL Desktop app sessions, ALL users with managed-mcp.json deployed
• Workaround: Delete managed-mcp.json — but this removes enterprise MCP governance
• Security impact: Organizations that need to enforce MCP server allowlists for compliance (ISO 27001 A.5.21, ISO 42001 A.6.2.11) cannot use the Desktop app

Suggested Fix

Two complementary changes:

1. CLI: When --strict-mcp-config is passed alongside enterprise MCP config, merge the configurations instead of rejecting. The enterprise config should take precedence (it has higher trust).

1. SDK: Capture stderr from the CLI subprocess and surface it in the Desktop app logs, so enterprise admins can diagnose configuration errors without reverse-engineering the binary.