Desktop App: Claude Code crashes with exit code 1 - SDK flag incompatibility (broken for 1+ week)

Status Fixed / completed
Reported on v2.1.87
Maintainer reply None cached
Activity 5 comments · opened Mar 29, 2026 · closed Mar 29, 2026

Bug Description

Claude Code in the Desktop App crashes immediately with exit code 1 when starting any local session. This has been broken for over a week (since ~March 22, 2026). The CLI works perfectly fine.

Root Cause

The Desktop App's SDK layer passes flags to the embedded Claude Code binary that it doesn't recognize. The binary exits immediately.

Evidence

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

[info] [CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0)
[info] Using Claude Code binary at: .../claude-code/2.1.87/claude.app/Contents/MacOS/claude
[error] Session local_... query error: Claude Code process exited with code 1
[info] [CCD CycleHealth] unhealthy cycle ... (0s, hadFirstResponse=false, reason=no_response)

Direct binary testing confirms the issue:

# Works fine:
claude -p "hi" --output-format json               # ✅
claude --plugin-dir <path> -p "hi"                 # ✅

# Flags the Desktop App seems to use:
claude --plugins <path> -p "hi"                    # ❌ error: unknown option '--plugins'
claude --sdk-metadata '{}' -p "hi"                 # ❌ error: unknown option '--sdk-metadata'

# Desktop App invocation:                          # ❌ exit code 1

Versions Tested

| Component | Version | Status |
|-----------|---------|--------|
| Desktop App | 1.1.8986 | ❌ Broken |
| Desktop App | 1.1.9493 | ❌ Broken |
| Embedded Claude Code | 2.1.78 | ❌ Crashes via Desktop |
| Embedded Claude Code | 2.1.87 | ❌ Crashes via Desktop |
| CLI Claude Code | 2.1.84 | ✅ Works fine |

Steps to Reproduce

  1. Open Claude Desktop App (1.1.9493)
  2. Open any local folder (e.g., create a test folder on Desktop)
  3. Send any message
  4. Claude Code spinner appears briefly then disappears — no response

What I've Tried

  • Reinstalled Desktop App (multiple times via brew reinstall --cask claude)
  • Deleted all caches (claude-code/, claude-code-vm/, claude-code-sessions/)
  • Reset bridge-state.json
  • Deleted local-agent-mode-sessions/
  • Deleted Session Storage/
  • Removed skills plugin directory
  • Clean binary re-download (server always delivers same version)
  • Updated Desktop App from 1.1.8986 → 1.1.9493
  • Contacted Anthropic support (received only generic troubleshooting steps)

Nothing fixes it because the issue is in how the Desktop App invokes the embedded binary.

Environment

  • Platform: macOS arm64 (Darwin 25.2.0)
  • Subscription: Max plan
  • Impact: Claude Code in Desktop App completely non-functional for 1+ week

Expected Behavior

Claude Code should respond to prompts in the Desktop App, same as it does via CLI.

View original on GitHub ↗

5 Comments

C2N1 · 5 months ago

This appears to be a widespread issue affecting multiple users. Related issues with the same root cause:

  • #37822 — Code mode crashes instantly (exit code 1) after Desktop app update
  • #36419 — Claude Desktop code mode crashes instantly with exit code 1 — VM never boots (macOS)
  • #39270 — Claude Code process exited with code 1

All report the same pattern: Desktop App code mode crashes with exit code 1, while CLI and chat mode work fine. Started around March 19-25, 2026.

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/40450
  2. https://github.com/anthropics/claude-code/issues/35430
  3. https://github.com/anthropics/claude-code/issues/37887

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

C2N1 · 5 months ago

As a Max plan subscriber ($100/month), I've been unable to use Claude Code in the Desktop App for over a week now. This is a core feature of the subscription that I'm paying for.

I understand that refunds may not be standard policy, but I would appreciate at the very least a credit or extension of my subscription period to compensate for the time this feature has been non-functional. Over a week of downtime on a premium subscription is significant.

Multiple users are affected by this issue (see linked issues above), and the only response from support so far has been generic troubleshooting steps that don't address the root cause.

I'd appreciate it if the team could consider some form of compensation for affected Max subscribers while this bug persists.

C2N1 · 5 months ago

Closing as duplicate of #40450. Added details there.

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.