[BUG] Claude Desktop code mode crashes instantly with exit code 1 — VM never boots (macOS Tahoe, v1.1.7714)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/35430
2. https://github.com/anthropics/claude-code/issues/31571
3. https://github.com/anthropics/claude-code/issues/35025

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

👎 None of these sound like the same issue. I don't think this is a duplicate.

Update — March 19, 2026 (evening)

Key new finding: Same build (v1.1.7714) works perfectly on two other Macs. This is not a packaging or distribution issue. Something is specific to this machine.

### What was tried and eliminated tonight:

• Removed entire ~/.claude directory — still crashes
• Removed all session data and skills plugin — still crashes
• Removed settings.local.json files — still crashes
• Deleted and re-downloaded VM bundle (10GB rootfs.img) — still crashes
• Removed hooks from settings.json — still crashes
• Fresh reinstall of Desktop app — still crashes
• Removed quarantine flags — still crashes
• Reset TCC privacy database — still crashes
• Added Claude to Developer Tools — still crashes
• Gatekeeper accepts app (Notarized Developer ID)
• Hypervisor support confirmed (kern.hv_support: 1)
• Firewall disabled
• No macOS update occurred
• XProtect unchanged since March 12
• Claude Code binary works perfectly from Terminal
• Chat mode works fine in Desktop app

### The crash pattern:

VM module loads ("Loading @ant/claude-swift module... Module loaded successfully") but never boots — no boot sequence, no guest connection, no SDK install.
kern.hv_vmm_present: 0 confirms no VM running.

### Timeline:

• March 17 evening: Code mode working fine
• March 18: No work done
• March 19 morning: Code mode broken — every session crashes instantly with exit code 1
• Nothing changed on the machine

### Request:

Since every local fix has been exhausted and the same build works on other machines, this may require server-side investigation (account-level, device ID, or feature
flag). Any guidance appreciated.

Adding info from my (probably) duplicate bug

I know you don't support Linux (shame, Anthropic, shame...), but I'll file this anyway.

The Cowork workspace consistently fails to start with "Request timed out: isGuestConnected". The VM bundle downloads successfully every time, but the VM never actually boots. The Electron process crashes internally before spawning any KVM/QEMU process.

What Should Happen?
Workspace starts and connects successfully after VM bundle downloads.

Actual behaviour:

[14:38:07] rootfs.vhdx.zst checksum validated — saved to cache
[14:38:09] vmlinuz.zst checksum validated — saved to cache
[14:38:14] initrd.zst checksum validated — saved to cache

Log then goes completely silent — no VM:steps, no start_vm, no wait_for_guest entries. No KVM or QEMU process ever spawns.
dmesg shows the Electron process hitting an int3 breakpoint trap at the exact time the VM boot should occur:

Error Messages/Logs

traps: electron[415028]
trap int3 ip:5598b952a8ab sp:7fff418b4590
error:0 in electron[72ad8ab,5598b490d000+9705000]

Steps to Reproduce

Launch Claude Desktop on Linux
Navigate to Cowork / "Let's knock something off your list"
App shows "Starting Claude's workspace..." indefinitely
After ~60 seconds: "Failed to start Claude's workspace — Request timed out: isGuestConnected"
Claude Model
None

Is this a regression?
Yes, this worked in a previous version

Last Working Version
Prior to 1.1.7714...sorry, I didn't capture it.

Claude Code Version
2.1.80 (Claude Code)

Platform
Anthropic API

Operating System
Other Linux

Terminal/Shell
Other

Additional Information
System checks (all passing)

/dev/kvm permissions: crw-rw-rw- (world accessible)
KVM modules loaded: kvm_amd + kvm confirmed via lsmod
virtiofsd installed: yes (Arch extra/virtiofsd 1.13.3-1)
Note: Arch installs virtiofsd to /usr/lib/virtiofsd not /usr/bin/ — symlink created to /usr/bin/virtiofsd

Additional Context

Previous version 1.1.7464 had a different failure: VM timed out on wait_for_guest with virtiofsd socket not ready errors, plus environments-2026-03-01 beta header API rejections blocking Cowork entirely
Version 1.1.7714 fixed the beta header issue but introduced the int3 crash
The new version also changed the VM bundle directory structure from flat claudevm.bundle/ to claudevm.bundle/wvm-/ — unclear if the boot code was updated to match

Bug: Code tab unresponsive in Claude Desktop App — claude-code-vm binary is Linux ELF, not macOS Mach-O

Claude Code CLI version: 2.1.78
Claude Desktop App version: Latest (as of March 20, 2026)
OS: macOS (Apple Silicon / ARM64)

What's Wrong?

The Code tab in the Claude Desktop App accepts input, briefly shows a response, then clears the screen and never renders output. The CLI works correctly when invoked via the VS Code plugin.

Root Cause Identified

The claude-code-vm binary shipped with 2.1.78 is a Linux ELF executable, not a macOS Mach-O binary. It cannot execute on macOS.

$ file ~/Library/Application\ Support/Claude/claude-code-vm/2.1.78/claude
/Users/.../claude-code-vm/2.1.78/claude: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0

$ file ~/Library/Application\ Support/Claude/claude-code/2.1.78/claude.app/Contents/MacOS/claude
/Users/.../claude.app/Contents/MacOS/claude: Mach-O 64-bit executable arm64

Running the VM binary directly confirms the error:

$ ".../claude-code-vm/2.1.78/claude" --version
zsh: exec format error

The .app bundle binary is correct (Mach-O arm64) and returns the expected version. The Code tab in the desktop app depends on the VM binary specifically, which is why the tab fails while the VS Code plugin works.

Steps to Reproduce

1. Install or update Claude Desktop App to latest version on Apple Silicon Mac
2. Open the Code tab
3. Enter any prompt
4. Observe: spinner appears briefly, screen flickers, no response rendered

Expected Behavior

Code tab responds normally, as it did prior to the 2.1.78 update.

Workaround

Use the Claude Code VS Code plugin, which uses a separate binary path and is unaffected.

Root cause confirmed: The file at ~/Library/Application Support/Claude/claude-code-vm/2.1.78/claude is a Linux ELF binary, not a macOS Mach-O binary.
Run file ~/Library/Application\Support/Claude/claude-code-vm/2.1.78/claude to verify. This is a server-side distribution bug — reinstalling doesn't help because the same wrong binary is re-downloaded. Chat and Co-work modes work because they don't use this binary.

Update: Root cause confirmed — wrong VM binary architecture

macOS: Darwin 25.3.0 (Apple Silicon)
Claude Desktop: Freshly reinstalled after macOS update
Claude Code CLI: Working perfectly
Chat mode: Working perfectly
Co-work mode: Working perfectly
Code mode: Crashes instantly, exit code 1

Root cause identified

The claude-code-vm binary that Claude Desktop auto-downloads is a Linux ELF executable, not a macOS Mach-O binary:

$ file ~/Library/Application\ Support/Claude/claude-code-vm/2.1.78/claude
ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked,
interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0

This should be a Mach-O 64-bit executable arm64 on macOS. The VM cannot execute, which is why Code mode crashes instantly while Chat and Co-work (which don't use this binary) work fine.

Key detail

Reinstalling Claude Desktop does NOT fix this because the VM binary is downloaded separately from Anthropic's distribution server after app installation. The server is serving the wrong architecture. Every reinstall pulls the same broken Linux binary.

Steps to reproduce

1. Install Claude Desktop on macOS Apple Silicon
2. Open Code mode
3. Observe instant crash (exit code 1)
4. Verify: file ~/Library/Application\ Support/Claude/claude-code-vm/2.1.78/claude shows ELF, not Mach-O

Impact

Code mode is completely unusable on macOS. This appears to be a server-side distribution issue affecting multiple users (see #36422, #36362, #36444, #36446, #36450, #36480, #36653, and earlier #26945 which was closed as stale without resolution).

This needs a server-side fix to serve the correct macOS binary.

Same issue here...

1st day with Claude has been disappointing to say the least. All the Hype is not worth it if you cannot address a critical bug within 24 Hours.

how do I rollback to older version ?

Update: I have switched back to Cursor with Opus 4.6 Max. Far better experience as a dev.

Major correction: Root cause is LOCAL_SESSION failure, NOT the VM binary

After examining the actual Desktop log files, my earlier diagnosis about the ELF binary was wrong. Here is what the logs actually show:

The VM is not even involved anymore

The VM log (claude_vm_swift.log) last ran on January 22. Code mode in current Desktop versions uses LOCAL_SESSION, not the VM. The ELF binary issue is irrelevant to this bug.

Actual errors from claude.ai-web.log (March 20-22, 2026):

2026-03-20 17:12:30 [warn] [LOCAL_SESSION] unknown sdk message type: rate_limit_event
2026-03-20 17:12:30 [warn] [LOCAL_SESSION] unknown sdk message type: rate_limit_event
2026-03-20 17:52:34 [error] [LOCAL_SESSION] Failed to send message [object Object]
2026-03-20 17:53:05 [error] [LOCAL_SESSION] Failed to send message [object Object]
2026-03-20 17:53:12 [error] [LOCAL_SESSION] Failed to send message [object Object]
2026-03-22 10:08:23 [error] [LOCAL_SESSION] Failed to send message [object Object]
2026-03-22 10:38:57 [error] [LOCAL_SESSION] Failed to send message [object Object]

Also present on every launch:

[REACT_QUERY_CLIENT] QueryClient error: Error: Not found
Content Security Policy blocking connections to https://a-api.anthropic.com/v1/m
Error sending segment performance metrics TypeError: Failed to fetch

User-facing symptom (corrected)

Code mode is not crashing. It opens, appears to load, but when you type a command and press Enter, nothing happens. No thinking indicator, no spinner, no error. Complete unresponsiveness. The logs confirm: Failed to send message.

Chat mode and Co-work mode both work. Terminal Claude Code works. Only Code mode's LOCAL_SESSION is broken.

Summary

This is the rate_limit_event regression (#36422). The local session encounters the unknown message type, the message queue breaks, and all subsequent sends fail silently. This matches the v1.1.7714 timeframe exactly.

Log file locations for other affected users to check:

• ~/Library/Logs/Claude/claude.ai-web.log
• ~/Library/Logs/Claude/claude_vm_node.log
• ~/Library/Logs/Claude/claude_vm_swift.log

Quick update: I've done some deep diagnostic testing via Terminal and found the exact root cause in the app's local session logs. It is not a cache or installation issue. Here is the full breakdown for your engineering team:

Subject: BUG: Code Mode UI Hard Crash (v1.1.7714) via Unhandled rate_limit_event in LOCAL_SESSION

To Anthropic Support / Engineering:

I am experiencing a persistent, silent UI crash in the Claude Desktop app (v1.1.7714 on macOS Apple Silicon) exclusively within Code Mode. Chat and Co-work modes function perfectly.

The Symptom:
When initiating a new Code mode session, the app accepts the first prompt, but the UI fails to render a response, spinner, or thinking indicator. Subsequent inputs are ignored entirely.

The Root Cause (Log Verified):
Diagnostic tailing of claude.ai-web.log reveals this is not the known ELF binary issue, as the app is utilizing LOCAL_SESSION. The frontend React UI is crashing due to an unhandled message type being broadcast by the backend API stream:

[LOCAL_SESSION] unknown sdk message type: rate_limit_event

[LOCAL_SESSION] Failed to send message [object Object]

[REACT_QUERY_CLIENT] QueryClient error: Error: Not found

The Feature Flag / A/B Test Discrepancy:
I have verified this is tied to my specific Anthropic account/feature flags. Fresh installs of the exact same v1.1.7714 Desktop client on other local macOS machines logged into different Anthropic accounts do not experience this crash. It appears my account is caught in an A/B test or rollout cohort where the backend is forcing the CLI to emit the new rate_limit_event status, which the current v1.1.7714 Desktop React frontend lacks the parser to handle, causing a fatal freeze.

Request:
Could you please either clear the specific GrowthBook feature flag on my account that is forcing this incompatible API stream behavior, or confirm if a v1.1.7715+ Desktop patch containing the updated SDK message parser is imminent?

Thank you.

Additional Report - Same Issue
I'm experiencing the identical problem on macOS (Apple Silicon).
Setup:

macOS, Apple Silicon
Claude Desktop 1.1.8629
Claude Code 2.1.78
Fresh reinstall on March 26, 2026

Issue:
Every message sent to a local Code session causes immediate crash:
Session [ID] query error: Claude Code process exited with code 1
Timeline:

Was working with local sessions for ~1 month
Relaunched Claude Desktop per user prompt
All local Code sessions became non-responsive
Lost all conversation history and project context

What I've tried:

✅ Cleared application cache (~/Library/Application Support/Claude/)
✅ Removed Claude Code VM (claude-code-vm/)
✅ Uninstalled/reinstalled Claude Desktop
✅ Removed all MCP servers
✅ Fresh macOS restart
❌ All attempts failed — same exit code 1 error

Current status:

Chat tab: ✅ Works perfectly
Code tab: ❌ Crashes every time
Direct Claude Code execution: ✅ Works (claude --print "test" succeeds)

Impact:

Cannot execute local code
Lost ~1 month of work context
Paid feature is completely non-functional

This suggests the issue is in how Claude Desktop spawns the Claude Code process, not the binary itself.

Update: Persistent 6-week unresolved issue — detailed diagnostic findings

I have been experiencing this bug for 6 weeks with zero resolution despite multiple support tickets and GitHub reports. I am a Claude Max subscriber and this tool is central to my daily workflow.
Environment:

Device: MacBook Pro (caesarkalinowski)
OS: macOS (Darwin)
Claude Desktop: latest version (updated multiple times over 6 weeks)
Claude Code binary: 2.1.101
Account: Claude Max subscription

Exact crash sequence from main.log:
[info] [CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0)
[info] Using Claude Code binary at: /Users/.../claude-code/2.1.101/claude.app/Contents/MacOS/claude
[error] Session local_39b56d5a-bed9-48ad-9bdb-d2f1b82a3752 query error: Claude Code process exited with code 1
[info] [CCD CycleHealth] unhealthy cycle for local_39b56d5a (0s, hadFirstResponse=false, reason=no_response)
Key findings:

Crash occurs at the exact moment the Desktop app passes the skills plugin to the Claude Code binary
Skills plugin manifest.json is valid and well-formed — not corrupted
Claude Code CLI in Terminal works perfectly
Chat and Cowork in Desktop work perfectly
Other users I have personally set up on identical Desktop versions do NOT have this problem
Ruled out: ANTHROPIC_API_KEY conflict, corrupted settings files, oversized CLAUDE.md, corrupted skills plugin

What I need:
An explanation for why the skills plugin handoff fails on my specific machine when it works on identical setups, and a path to resolution that doesn't involve waiting indefinitely with no response.
I am happy to provide any additional logs, run any diagnostic commands, or participate in a direct troubleshooting session. I simply need a real human response after 6 weeks.

[BUG] I am facing the same issue. everytime i switch on code on MacOS Tahoe 26.4.1 Claude 1.3109.0 crashes

[BUG] I am facing the same issue. everytime i switch on code on MacOS Tahoe 26.4.1 Claude 1.3109.0 crashes[BUG] 我遇到了同样的问题。每次在 MacOS Tahoe 26.4.1 上启用代码时，Claude 1.3109.0 都会崩溃

I also encountered the same problem. Has it been resolved?

Same here!!

Update — still reproducing on latest bundled binary (v2.1.119), Desktop v1.1.7714+
Confirming this bug is still present as of April 27, 2026. Six weeks since I originally filed.
New data point: Reproduces cleanly on the latest bundled Claude Code binary (v2.1.119, auto-downloaded today), so this is not a stale-version issue. Same exact log signature as the original report:
[CCD] Using skills plugin at: .../local-agent-mode-sessions/skills-plugin/...
[CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0)
Using Claude Code binary at: .../claude-code/2.1.119/claude.app/Contents/MacOS/claude
[error] Session local_... query error: Claude Code process exited with code 1
[CCD CycleHealth] unhealthy cycle (0s, hadFirstResponse=false, reason=no_response)
Crash is <1 second, hadFirstResponse=false. Standalone CLI works perfectly with the same bundled binary.
This appears to be the same root cause as #37887, #39270, and #49041 — all show identical "Passing N plugin(s) to SDK (skills: 1...)" → exit code 1 signatures across Desktop versions from v1.1.7714 → v1.2773.0 and bundled binaries from v2.1.78 → v2.1.119.
Environment: macOS Tahoe, Node v24.12.0, Claude Max subscriber, 9 enabled skills.
Happy to provide full main.log excerpts, run targeted diagnostics, or test a fix candidate. Six weeks of silence on a paid tier is a long time — would appreciate any acknowledgment from the team that this is being looked at.

Additional diagnostic, same day:
Tested whether disabling skills prevents the crash. It does not.
Disabled all 4 user-toggleable skills in Desktop Settings, fully quit and reopened the app, then triggered Code mode. Log still shows:
[CCD] Using skills plugin at: .../local-agent-mode-sessions/skills-plugin/...
[CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0)
[error] Session local_... query error: Claude Code process exited with code 1
[CCD CycleHealth] unhealthy cycle (0s, hadFirstResponse=false, reason=no_response)
The skills plugin is passed to the SDK regardless of the user-facing skill toggles. This rules out individual skill content as the trigger and points the bug squarely at the Desktop app's SDK invocation layer.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.