Desktop app crash loop on macOS Tahoe 26.5.1 arm64: CCD bundle truncated to 172MB, errno -88; renderer v8-oom on /epitaxy route

Summary

Claude Desktop app v1.11187.1 on macOS Tahoe 26.5.1 (Darwin 25.5.0, arm64, M-series, 16GB) hits two reproducible crashes that compound into a launch loop.

Issue 1: CCD bundle extraction truncates binary

On every fresh install of CCD bundle 2.1.161, the in-app extractor writes only ~172MB of the 218MB claude.app/Contents/MacOS/claude binary. The truncated Mach-O has LC_CODE_SIGNATURE pointing to offset 216,331,456 — past EOF.

Result: posix_spawn returns errno -88 (ESHLIBVERS), logged as:

[CCD] Binary preflight: .verified marker missing but binary exists ... Proceeding with spawn.
Error: spawn Unknown system error -88

This breaks Failed to get commands from temporary query and Failed to get agents from temporary query on every launch.

Verification: downloading the same https://downloads.claude.ai/claude-code-releases/2.1.161/darwin-arm64/claude.app.tar.zst (44.87MB) and decompressing with system zstd yields the full 218,040,864-byte binary. So the server artifact is correct; the app-side zstd/tar pipeline is dropping the tail. Reproducible across multiple re-downloads.

Workaround that fixed it locally: manual download → zstd -d → tar x → drop into ~/Library/Application Support/Claude/claude-code/2.1.161/claude.app/ → codesign --force --sign - → touch .verified marker.

Issue 2: Renderer v8-oom on /epitaxy route

After CCD is fixed, every launch routes to https://claude.ai/epitaxy and the renderer crashes within seconds. Crashpad minidumps consistently contain:

electron.v8-oom.is_heap_oom
electron.v8-oom.location

RSS at crash time only ~360–400MB, so this is V8 old-space exhaustion in the isolate, not system OOM. Deleting all chats from the web UI did not change behavior (still routes to /epitaxy).

unknown-window.log also shows on every launch:

Setting the document's base URI to 'https://claude.ai/' violates ... base-uri 'none'
Uncaught (in promise) Error: Error invoking remote method '...claude.buddy_BuddyBleTransport_reportState': No handler registered

And claude.ai-web.log shows repeated MaxListenersExceededWarning on AutoUpdater_updaterState, CoworkScheduledTasks_onScheduledTaskEvent, AppPreferences_preferencesChanged — suggests listener leak across IPC bridge.

Issue 3 (minor): rootfs.img re-downloads from 0 every launch

The 2GB rootfs.img.zst download (https://downloads.claude.ai/vms/linux/arm64/5680b11bcdab.../rootfs.img.zst) does not appear to resume — every launch restarts from 0%. Combined with frequent renderer crashes from Issue 2, the VM never finishes downloading, so cowork/workspace features stay stuck on vmStatus=booting after 5001ms wait.

Environment

• Claude Desktop: 1.11187.1 (370d3b) 2026-06-04T17:30:35.000Z
• macOS: Tahoe 26.5.1 (Darwin 25.5.0)
• Arch: arm64, Apple Silicon, 16GB RAM, 108GB free
• Node (in app): 24.15.0
• Fresh reinstall + reboot did not help