[BUG] claude.exe crash on Windows 11 Arm64 with 0xC0000005

claude.exe crashes with 0xC0000005 in --print stream-json mode on Windows 11 ARM64

Summary

On Windows 11 ARM64, the bundled claude.exe (an x64 binary running under Prism emulation)
crashes with an access violation (0xC0000005 / exit code 3221225477) roughly 30–65% of the
time whenever it is launched in SDK streaming mode — the exact mode Claude Desktop uses for every
local session. It produces no stderr output at all before dying.

Two follow-on bugs make this much worse than it needs to be:

1. The crash report can never be submitted. The "Submit feedback / bug report" dialog routes

through the crashed session's active query, which no longer exists — so it always fails with
"Couldn't send feedback."

1. The child's stderr is discarded, so main.log records only the exit code with zero

diagnostic information. No WER report or crash dump is produced either.

Environment

| | |
|---|---|
| OS | Windows 11 Enterprise 10.0.26100 |
| Machine | ARM64-based PC (ARMv8, 64-bit) |
| Claude Desktop | 1.24012.9 (%LOCALAPPDATA%\AnthropicClaude\app-1.24012.9) |
| Claude Code | 2.1.219 (%APPDATA%\Claude\claude-code\2.1.219\claude.exe) |
| claude.exe PE machine type | 0x8664 (x64) — i.e. running emulated, not ARM64-native |
| RAM | 16 GB, ~10 GB free at crash time (not memory pressure) |

Reproduction

Spawn the bundled binary in SDK streaming mode with stdio redirected, drain stdout/stderr properly,
then close stdin:

claude.exe --print --output-format stream-json --input-format stream-json --verbose

Results over repeated runs from C:\msbuild:

| Variant | Crash rate |
|---|---|
| stream-json in/out, close stdin immediately, send nothing | 3 / 10 crashed 0xC0000005 |
| stream-json in/out, send initialize control request, then close stdin | 6 / 10 crashed 0xC0000005 |
| stream-json in/out, initialize, longer run (separate batch) | 13 / 20 crashed 0xC0000005 |
| claude.exe mcp list | 0 / 10 — always clean |
| claude.exe --version | 0 / 25 — always clean |

Notes:

• The crash happens with no request sent at all, so it is not tied to handling any particular

control request — it is in streaming-mode startup/teardown itself.

• Timing varies: in some runs the process dies before emitting a single byte of stdout; in

others it emits the complete ~15 KB initialize control response successfully and then crashes
on exit instead of returning 0.

• Non-streaming subcommands never crash (35/35 clean), which points at the streaming/stdio path

rather than general startup.

• stderr is always empty. No V8 fatal error, no stack, nothing.

Impact in the app

%APPDATA%\Claude\logs\main.log covers 2026-07-26 → 2026-08-02 and contains 68 distinct
failures attributable to this crash:

| Log message | Count |
|---|---|
| Failed to get agents from temporary query | 50 |
| Failed to get commands from temporary query | 9 |
| Session <id> query error: Claude Code process exited with code 3221225477 | 6 |
| Failed to get SDK commands for <id> | 3 |

Spread across 4 days of use: 24 on 07-26, 23 on 07-27, 2 on 08-01, 19 on 08-02.

The 6 session-level ones are the user-visible "Claude Code crashed" dialogs. The rest are silent
degradation — agent and slash-command discovery failing in the background.

Representative entry:

2026-08-02 21:11:29 [error] Failed to get SDK commands for local_b35a88c1-… {
  error: Error: Claude Code process exited with code 3221225477
      at qQ.getProcessExitError (…\app.asar\.vite\build\index.chunk-41sTXhtI.js:100:8497)
      at ChildProcess.n (…:100:12438)
      at ChildProcess._handle.onexit (node:internal/child_process:295:12)
}
2026-08-02 21:11:29 [info] [CCD CycleHealth] unhealthy cycle for local_b35a88c1-…
      (11s, hadFirstResponse=false, reason=no_response)

Bug 2 — feedback submission is structurally impossible after a crash

Every attempt to use the crash dialog fails. From main.log:

2026-08-02 21:11:54 [info] [CCD] LocalSessions.submitFeedback: sessionId=local_b35a88c1-…, descLen=160
2026-08-02 21:11:54 [warn] [CCD] Cannot submit feedback: session local_b35a88c1-… not found or has no active query

20 such attempts are logged across two sessions (descLen 160 and 373), all rejected. The submission
path requires the session to have a live query — but the reason the user is filing feedback is that
that very process just died. The "Get help" button in the same dialog also does nothing.

Feedback about a crash should not be sent through the crashed process. It needs an
out-of-band path that only requires the session id and transcript on disk.

Bug 3 — no diagnostics captured

• The child's stderr is not written to main.log, so a native crash leaves no trace beyond the

numeric exit code.

• No %LOCALAPPDATA%\CrashDumps entries and no WER reports exist for claude.exe.
• Sentry captures the parent's JS exception ("Claude Code process exited with code …"), which

contains no information about the actual fault.

Capturing the last N KB of child stderr, and enabling a crash dump for the SEA binary, would make
this diagnosable.

Suggested fixes

1. Ship an ARM64-native claude.exe for Windows on ARM, or investigate the x64/Prism emulation

fault in streaming mode (likely V8/JIT or a libuv stdio teardown path).

1. Decouple feedback submission from the live session query.
2. Capture and log child stderr on non-zero exit.

Reproducing this on x64, not ARM64 — so this may not be
Prism emulation specific.

Environment:

• Windows 11 Pro (build 26100), x64 (Intel), no emulation involved
• Native installer (irm https://claude.ai/install.ps1 | iex)
• Reproduced on 2.1.234 and 2.1.220

Matches your findings exactly:

• claude --version, claude doctor, claude auth login: always clean
• claude -p "hi": exit code -1073741819 (0xC0000005), 100% of runs,

no stdout, no stderr

• Interactive TUI: renders fully, crashes right after confirming

the folder trust prompt

• No Application event log entry, no CrashDumps, no WER report

Ruled out on my side:

• Deleted ~\.local\bin\claude.exe and ~\.local\share\claude,

reinstalled clean

• Renamed ~\.claude and ~\.claude.json aside, went through

first-run setup and login again

• Empty project directory
• Windows Terminal and conhost both
• All Claude Desktop processes terminated

Crash rate here is 100%, not intermittent. Notably the CLI worked
correctly right after the initial native install, and started
failing on every invocation after running claude inside the VS Code
integrated terminal (which auto-installed the anthropic.claude-code
extension). Unclear whether that's causal.

• Windows 11 Pro (build 26100), Intel Core i5-14500 (x64 native,

no emulation)

Additional data point: on my machine the crash is 100% reproducible,
not intermittent.

The trigger appears to be the VS Code extension. Sequence:

1. Clean native install. claude doctor reported "No installation

issues found". Interactive sessions ran normally. Confirmed
working.

1. Ran claude inside the VS Code integrated terminal once. This

auto-installed the anthropic.claude-code extension.

1. Every invocation since then crashes with 0xC0000005, in every

directory, in every terminal.

The extension has since been removed from disk, and the crash
persists. Deleting the binary entirely (~\.local\bin\claude.exe and
~\.local\share\claude) and reinstalling clean does not fix it.
Renaming ~\.claude and ~\.claude.json aside and going through
first-run setup again does not fix it either. Whatever changed
survives both a binary reinstall and a config reset.

One leftover I did find: ~\.vscode\extensions\extensions.json still
contains an anthropic.claude-code entry (version 2.1.111,
"pinned": true, "updated": true) even though the extension folder
is gone.

Additional data point: reproducing this on x64, not ARM64, so this
is not specific to Prism emulation.

Environment:

• Windows 11 Pro (build 26100), Intel Core i5-14500, x64 native
• Native installer (irm https://claude.ai/install.ps1 | iex)
• Node.js not installed
• Reproduced on 2.1.234 and 2.1.220

100% reproducible, not intermittent. Matches your streaming vs
non-streaming split exactly:

• claude --version, claude doctor, claude auth login: always clean
• claude -p "hi": exit -1073741819 (0xC0000005), no stdout, no

stderr, every single run

• Interactive TUI: renders the full banner and trust prompt, then

dies immediately on the first query

Verified from a completely clean state: removed everything (binary,
~\.claude, ~\.claude.json, npm global package, Node.js, VS Code
extension), then installed only the CLI via the native installer.
claude doctor reports no issues. First query crashes.

No Application event log entry, no CrashDumps, no WER report —
same as you observed.

The Microsoft Store build of the Claude desktop app
(Claude_1.32352.0.0_x64) works normally on the same machine, so
this looks specific to the standalone CLI binary rather than the
environment.

Found a working version: 2.1.111 runs correctly on this machine.

• 2.1.111 -> claude -p "hi" returns a response, exit 0
• 2.1.220 -> exit -1073741819 (0xC0000005)
• 2.1.234 -> exit -1073741819 (0xC0000005)

All three installed via the same native installer on the same
machine, so this is a regression somewhere between 2.1.111 and
2.1.220 rather than an environment issue.

Important data point: this is not version-dependent, it's
distribution-dependent.

On the same machine (Windows 11 Pro, Intel Core i5-14500, x64
native, no emulation):

• 2.1.111 via npm (npm install -g @anthropic-ai/claude-code@2.1.111)

-> works correctly, interactive sessions included

• 2.1.111 via native installer

-> crashes with 0xC0000005

• 2.1.220 via native installer -> crashes
• 2.1.234 via native installer -> crashes

Same version, same machine. The npm build (which runs on Node.js)
works; the native SEA binary does not. So the fault appears to be
in the single-executable build itself rather than in application
code or the environment.

This also affects the desktop app: the Code tab shows "Claude Code
crashed" because it spawns the native binary in streaming mode.
Cowork works normally on the same machine.