Claude Code Desktop mode crashes: --resume-session-at flag not recognized by bundled binary 2.1.78

Bug Description

Claude Code mode in the Claude Desktop app (macOS, Apple Silicon) is completely non-functional. Every message sent in Code mode fails silently — the Claude Code process exits with code 1 immediately.

Environment

• Claude Desktop: v1.1.7714 (latest as of 2026-03-22)
• Bundled Claude Code binary: 2.1.78 (downloaded by Desktop from downloads.claude.ai/claude-code-releases/2.1.78/darwin-arm64/claude.app.tar.zst)
• Global CLI: 2.1.81 (works fine in Terminal)
• Platform: macOS Darwin 24.6.0, Apple Silicon (arm64)

Root Cause

The Desktop app passes --resume-session-at as a CLI argument when spawning the Claude Code binary, but this flag does not exist in the bundled 2.1.78 binary (nor in 2.1.81). The binary rejects the unknown flag and exits with code 1 before any stdin can be written.

Evidence from logs (~/Library/Logs/Claude/main.log)

[info] Using Claude Code binary at: ~/Library/Application Support/Claude/claude-code/2.1.78/claude.app/Contents/MacOS/claude
[error] Sentry caught: { type: 'Error', value: 'ProcessTransport is not ready for writing' }
[error] Session local_xxx query error: Claude Code process exited with code 1
[info] [CCD CycleHealth] unhealthy cycle (0s, hadFirstResponse=false, reason=no_response)

This pattern repeats for every session (old and new), across multiple app restarts and binary re-downloads.

Reproduction

1. The Desktop app passes --resume-session-at (confirmed via strings app.asar)
2. The binary does not support this flag:

``
$ claude --help | grep resume-session-at
(no output)
``

1. Direct test confirms crash:

``
$ claude -p --session-id "local_xxx" < /dev/null
Error: Invalid session ID. Must be a valid UUID.
``

Additional Notes

• The binary works perfectly when invoked directly (claude -p "hello" returns a response)
• The local_ prefixed session IDs also fail UUID validation when passed via --session-id
• Deleting and re-downloading the binary does not help — Desktop always re-downloads 2.1.78
• Replacing the binary manually is blocked by com.apple.provenance xattr (and Desktop re-downloads anyway)
• The VM (Virtualization Framework) is healthy and boots correctly — this only affects the local binary execution path

Expected Behavior

The Desktop should pass only flags that the bundled binary version supports, or the binary should be updated to support --resume-session-at.