Claude Code v2.1.112+ crashes with Segmentation Fault (0xc0000005) on Windows 11

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/49814
2. https://github.com/anthropics/claude-code/issues/50187
3. https://github.com/anthropics/claude-code/issues/50559

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

Confirming this issue on a different Windows setup — affects more than just Windows 11.

My setup (different from OP):

• OS: Windows 10 (fully updated, fresh install done during troubleshooting)
• Hardware: HP EliteBook 6930p (Intel Core 2 Duo)
• Node.js: v24.14.1
• npm: 11.11.0

Version testing results:

• ✅ v2.1.112 — works
• ❌ v2.1.114 — crashes
• ❌ v2.1.116 — crashes

My break point is slightly different from OP (v2.1.112 works for me but crashes for OP), suggesting the native binary has different crash triggers across systems.

Crash details from Event Viewer (same exception code as OP):
Faulting application name: claude.exe, version: 2.1.116.0
Faulting module name: ntdll.dll, version: 10.0.19041.1806
Exception code: 0xc0000005 (ACCESS_VIOLATION)
Fault offset: 0x0000000000063416

Troubleshooting that did NOT fix it:

• Fresh Windows 10 install
• sfc /scannow + DISM repairs
• Reinstalling Visual C++ Redistributables
• Disabling antivirus
• New Windows user account
• Windows Memory Diagnostic (no RAM errors)
• Native installer (irm https://claude.ai/install.ps1 | iex) — same crash
• VS Code extension bundled binary — same crash

Only working solution: Downgrade to v2.1.112 and set DISABLE_AUTOUPDATER=1.

This confirms the bug is in the native Windows binary, affects diverse Windows systems (both Win10 and Win11, both old and new hardware), and urgently needs attention as auto-update silently breaks working installations.

Thank you so much for your response. After manually installing v2.1.112, Claude Code works perfectly.

I also manually adjusted the Claude Code link in Claude Code Desktop, and Claude Code Desktop can now use cowork and code.

However, Claude should resolve this issue as soon as possible. The new version cannot be installed, and even if the installation fails, it will show as successful, there are no log records.

Same here - v2.1.112 — works using mingw shell
"C:\git-sdk-64\msys2_shell.cmd" -defterm -no-start -mingw64"

Same here, downgrade to v2.1.112

I tried updating to the latest today and still, it's segment faulting.

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

Confirming this is still happening on much newer versions, and it's specifically the Claude Desktop app's "Code" / cowork feature — not the standalone CLI installer discussed above.

Setup:

• Windows 11, ARM64-based PC (Snapdragon/Copilot+ class — confirmed via systeminfo → "System Type: ARM64-based PC", not an x64 machine under emulation)
• Claude Desktop app's Code feature downloads its own claude.exe to %APPDATA%\Claude\claude-code\<version>\claude.exe
• As of 2026-07-08: Desktop app on 2.1.202, still crashes with exit code 3221225477 (0xC0000005 / STATUS_ACCESS_VIOLATION)

Root cause (confirmed via PE header inspection): the binary the Desktop app downloads to that path is x64 (PE machine type 0x8664), even though it's running on ARM64 hardware. Meanwhile, the Claude Code VS Code extension, installed side-by-side on the same machine, correctly ships a native ARM64 claude.exe (PE machine type 0xAA64) inside its own package at <extension-dir>\resources\native-binary\claude.exe. So a correct ARM64 build does exist and is being distributed through the VS Code extension channel — it's just not what the Desktop app fetches for its Code feature.

Workaround (not durable): manually copy the VS Code extension's ARM64 claude.exe over the Desktop app's claude-code\<version>\claude.exe, and update the sibling .verified file with the new binary's SHA256 so the app doesn't flag it as tampered. This resolves the crash immediately, but reverts every time either the Desktop app or the VS Code extension auto-updates (observed recurring roughly weekly, both via in-place "self-heal" re-downloads of the same version and via version bumps to a new claude-code\<version>\ folder).

Suggestion: since Anthropic is already building and distributing a correct ARM64 binary for the VS Code extension, it seems like the Desktop app's Code/cowork feature could use that same ARM64 build (or the same build pipeline/detection logic) on ARM64 Windows instead of always fetching x64.

Happy to provide more diagnostic details if useful.