Claude Desktop 1.24012.9 hangs at _dyld_start on macOS 26.5 arm64 — surfaces as "is damaged and can't be opened"; v0.14.10 launches fine on same machine

Summary

Claude Desktop 1.24012.9 cannot launch on macOS 26.5 (arm64). The process is created but hangs indefinitely at _dyld_start with a 96 KB physical footprint and 0% CPU — dyld never maps a single library, so no application code ever runs.

macOS surfaces this to the user as "Claude is damaged and can't be opened. You should move it to the Trash." That message is misleading: the bundle is intact and passes every signature and notarization check. Users following the dialog's advice delete a perfectly valid app and reinstall it repeatedly with no effect.

v0.14.10 launches normally on the same machine, same signing identity, same session. This is a build regression, not a download, quarantine, or machine-level problem.

Environment

| | |
|---|---|
| macOS | 26.5 (25F71) |
| Hardware | Apple M1, arm64 |
| Broken build | 1.24012.9 (signed Jul 24 2026) |
| Working build | 0.14.10 (signed Oct 28 2025) |
| MDM / security software | None enrolled, systemextensionsctl list → 0 extensions, no third-party kexts |

Reproduction

1. Download Claude Desktop 1.24012.9 from claude.ai/download
2. Install to /Applications (Finder drag or ditto — same result)
3. Launch via Finder → "Claude is damaged and can't be opened"

Launching the executable directly shows the real behavior — it hangs rather than erroring:

$ /Applications/Claude.app/Contents/MacOS/Claude &
$ sample <pid> 3

Physical footprint:  96K
Call graph:
    2587 Thread_15510: Main Thread   DispatchQueue_<multiple>
      2587 _dyld_start  (in dyld) + 0  [0x1041409c0]

100% of samples at _dyld_start. sample also reports Couldn't find _sigtramp symbol in expected dylibs — libSystem was never loaded. The process stays in this state indefinitely.

The bundle is valid

$ hdiutil verify Claude.dmg
checksum of "Claude.dmg" is VALID

$ codesign --verify --deep --strict /Applications/Claude.app
(exit 0)

$ spctl -a -vvv -t exec /Applications/Claude.app
accepted
source=Notarized Developer ID
origin=Developer ID Application: Anthropic PBC (Q6L2SF6YDW)

$ codesign -dv --verbose=4 /Applications/Claude.app
Notarization Ticket=stapled
Timestamp=Jul 24, 2026 at 1:08:06 AM
Runtime Version=26.2.0

Ruled out

Each of these was tested and made no difference:

• Corrupt download — DMG checksum valid; the app bundle deep-verifies and is notarized with a stapled ticket
• Quarantine / Gatekeeper — xattr -dr com.apple.quarantine removed all attributes (verified 0 remaining); dialog persisted, changing only to "downloaded on an unknown date"
• Wedged syspolicyd / amfid / XProtect — full reboot; identical hang afterward
• Disk I/O — read the entire 391 MB Electron Framework at 2.7 GB/s, no errors
• Copy method — ditto (753 MB, byte-complete) and Finder drag both produce the same hang
• Stale LaunchServices state — lsregister -f re-registration, no change
• Environment injection — no DYLD_* vars set in shell or launchd; env -i launch hangs identically
• Architecture — arch -x86_64 (Rosetta, x86_64 slice) hangs identically
• Stale Squirrel state — removed ~/Library/Caches/com.anthropic.claudefordesktop.ShipIt entirely before a clean install

Control: /bin/echo and a freshly-copied Calculator.app both launch normally, so exec is not broken system-wide.

Decisive comparison

Both builds tested back-to-back on the same machine, both Developer ID Anthropic PBC (Q6L2SF6YDW), both notarized, both passing codesign --verify --deep --strict:

| Build | Result |
|---|---|
| 1.24012.9 | Hangs at _dyld_start, 96 KB footprint, 0 helper processes |
| 0.14.10 | Launches normally — 5 helper processes, real Electron/V8 run loop, window renders, authenticates to the API |

v0.14.10 stack confirming a healthy launch:

Call graph:
    2308 Thread_22512: CrBrowserMain
    + 2308 start  (in dyld) + 6992
    +   2308 ElectronMain  (in Electron Framework) + 124
    +     2308 node::...

Related

Likely the same underlying defect behind the "damaged" reports in #56234, #57183, and #56754, which have been attributed to signing/notarization. The evidence here suggests notarization is not the cause — Gatekeeper accepts the bundle — and that the failure is in dyld/AMFI image loading for this build.

Impact

The "damaged" dialog leads users to delete and re-download repeatedly, which cannot fix a build regression. Several existing issues show exactly that loop.

Workaround

Install v0.14.10 and prevent Squirrel from auto-updating back to the broken build. Both measures stay outside the app bundle so its signature remains intact:

launchctl disable gui/$(id -u)/com.anthropic.claudefordesktop.ShipIt
chmod 500 ~/Library/Caches/com.anthropic.claudefordesktop.ShipIt
chflags uchg ~/Library/Caches/com.anthropic.claudefordesktop.ShipIt

Suggested triage

A quick way to test any candidate build: launch Contents/MacOS/Claude directly and sample the PID. If every frame sits at _dyld_start after 3+ seconds, that build will present as "damaged" to end users regardless of signing.