[BUG] Desktop app: local Claude Code session exits with code 1 in 0s (CCD 2.1.138 + Claude.app 1.7196.0)

Bug Report: Claude Code session crashes immediately when launched from Claude desktop app

Summary

Every local Claude Code session started from the Claude desktop app exits with code 1 in under 1 second, before any first response. The session UI appears but no model output is ever produced. The bundled Claude Code binary itself is functional — the crash is specific to how the desktop app spawns and configures the SDK session.

Environment

• OS: macOS 25.2.0 (Darwin arm64)
• Claude desktop app: 1.7196.0
• Bundled Claude Code (used by the app): 2.1.138
• npm-global Claude Code (used in terminal): 2.1.143 — works fine
• Account: Pro/Max tier, OAuth via claude.ai
• Working directory tested: /Users/habib

Steps to reproduce

1. Open Claude desktop app
2. Create a new local Claude Code session in /Users/habib
3. Send any message (e.g. "Hello")

Expected

Model responds.

Actual

Session immediately fails. Log shows:

2026-05-16 21:44:37 [error] Session local_28502f0b-... query error: Claude Code process exited with code 1
2026-05-16 21:44:37 [info] [CCD CycleHealth] unhealthy cycle for local_28502f0b-... (0s, hadFirstResponse=false, reason=no_response)

Stack trace (from ~/Library/Logs/Claude/main.log):

Error: Claude Code process exited with code 1
    at fbi.getProcessExitError (app:///.vite/build/index.js:406:8370)
    at ChildProcess.i (app:///.vite/build/index.js:406:11414)
    at Object.onceWrapper (node:events:631:26)
    at ChildProcess.emit (node:events:521:24)
    at ChildProcess._handle.onexit (node:internal/child_process:295:12)

Reproduced 6 times across multiple app launches and a clean bundle reinstall (2026-05-16 21:02, 21:12, 21:19, 21:39, 21:44, 21:47).

Key spawn context from logs

[CCD] Using skills plugin at: ~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/...
[CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0)
Using Claude Code binary at: ~/Library/Application Support/Claude/claude-code/2.1.138/claude.app/Contents/MacOS/claude
[CCD] [replaceRemoteMcpServers] Calling SDK with 7 total servers {
  serverNames: [
    'Claude in Chrome',
    'mcp-registry',
    'Claude Preview',
    'ccd_session',
    'ccd_directory',
    'ccd_session_mgmt',
    'scheduled-tasks',
  ]
}

Diagnostic that isolates the bug

The bundled binary at ~/Library/Application Support/Claude/claude-code/2.1.138/claude.app/Contents/MacOS/claude works correctly when invoked directly:

1. One-shot prompt:

``
$ ".../claude" --print "Hello"
Hello! How can I help you today?
exit=0
``

1. SDK stream-json mode (same protocol the app uses) — also in /Users/habib, also Sonnet 4.6:

``
$ echo '{"type":"user","message":{"role":"user","content":"Hello"}}' | \
".../claude" --output-format=stream-json --input-format=stream-json --verbose
{"type":"result","subtype":"success","is_error":false,"duration_ms":1679,
"result":"Hello! How can I help you today?", ...}
exit=0
``

The standalone SDK-mode run loaded 3 MCP servers (Gmail, Calendar, Drive — all needs-auth) and plugins: [], and it completed successfully in 1.7 seconds.

The desktop-app-spawned session passes 7 different internal servers and 1 skills plugin, and crashes in 0 seconds. The trigger is therefore in the desktop app's session configuration (the 7 internal MCP servers, the skills plugin, or the spawn arguments), not the bundled binary itself.

Things that did not fix it

• Quit and relaunch Claude.app
• Delete cached bundle ~/Library/Application Support/Claude/claude-code/2.1.138 and let app re-download (fresh 42.5MB bundle installed cleanly)
• Adding /Users/habib/Documents as an additional session directory (session cwd remained /Users/habib)

Workaround

Run Claude Code from terminal (claude v2.1.143) instead of from the desktop app — fully functional.

Logs

~/Library/Logs/Claude/main.log — relevant timestamps above.

The desktop app's error log only surfaces the JS-side "exited with code 1"; it does not capture the bundled binary's stdout/stderr at spawn. Capturing that stream when spawning from the app would make this much easier to diagnose further.