Claude Code / Cowork VM fails to start on Linux ARM64 (Raspberry Pi 5) — "binary is missing or damaged"

Environment

• Device: Raspberry Pi 5
• OS: Debian GNU/Linux 13 (trixie), 64-bit
• Architecture: aarch64 (confirmed via uname -m)
• Claude Desktop version: 1.37937.1 (installed via apt, already the latest available)
• Standalone Claude Code CLI: works fine, v2.1.246, installed via curl -fsSL https://claude.ai/install.sh | bash

Symptom

Opening the Code tab in Claude Desktop shows:

Claude Code couldn't start The Claude Code binary is missing or damaged. Reinstall Claude Desktop to continue. No path to Claude code executable (Download failed. Check your internet connection and try again.)

What's been ruled out

• Network connectivity to downloads.claude.ai works fine (curl -sI https://downloads.claude.ai/claude-code-releases/latest → HTTP/2 200)
• Architecture is supported (aarch64 / linux-arm64)
• Disk space is not an issue (104G free)
• /dev/kvm exists and the user is in the kvm group (verified after re-login)
• Killing all claude-desktop processes (including pkill -9) and relaunching cleanly does not help
• Manually removing the stale target paths does not help — they are recreated identically on every launch

Root cause (from logs)

~/.config/Claude/logs/main.log and ~/.config/Claude/logs/cowork_vm_node.log show the actual error is not a network failure but a filesystem conflict: the app appears to create these paths as empty directories on startup, then tries to open() the same path as a writable file to store the downloaded binary/bundle, which fails with EINVAL:

[error] [ClaudeCodeManager-VM] Download attempt 3/3 failed Error: EINVAL: invalid argument, open '/home/amax/.config/Claude/claude-code-vm/2.1.246'
    at async open (node:internal/fs/promises:640:25)
    at async l9t.downloadBinaryForTarget (...)
    at async l9t.prepareForTarget (...)
    at async l9t.prepareForVM (...)
[error] [ClaudeCodeManager-VM] All download attempts failed

[error] [download] VM download failed: EINVAL: invalid argument, open '/home/amax/.config/Claude/vm_bundles/claudevm.bundle'
[warn] [VM:start] Download failed, leaving VM offline (no auto-reinstall — bundle never reached disk)

ls -la on these paths confirms they are directories, not files:

/home/amax/.config/Claude/claude-code-vm/2.1.246/   (empty directory)
/home/amax/.config/Claude/claude-code/2.1.246/      (empty directory)
/home/amax/.config/Claude/vm_bundles/claudevm.bundle/  (empty directory)

stat on claude-code-vm/2.1.246 shows its birth time matches the app's process start time exactly, confirming the app itself creates this directory at every launch, before ever attempting the download — i.e., this isn't leftover state from a prior crash, it's the app's own startup behavior on this platform.

Expected behavior

The download/prepare step should write the binary to a file path distinct from any directory the app manages, or should not pre-create a directory at the exact path it later tries to open() as a file.

Workaround in use

Using the standalone Claude Code CLI directly in a terminal (claude), which works correctly and is unaffected by this bug. Only the Desktop app's integrated Code tab (which spins up a local VM via cowork-linux-helper) is affected.

Reproduction steps

1. Install Claude Desktop on a Raspberry Pi 5 running 64-bit Debian/Raspberry Pi OS via the official apt repo.
2. Sign in.
3. Open the Code tab.
4. Observe the "binary is missing or damaged" error.
5. Confirm in ~/.config/Claude/logs/main.log and ~/.config/Claude/logs/cowork_vm_node.log that the failure is EINVAL: invalid argument, open ... rather than an actual network error.