claude.exeがWindows ARM64でクラッシュする原因と対処法(0xC0000005)

Windowsで claude.exe を実行すると、0xC0000005(アクセス違反)を伴う終了コード 3221225477 でプロセスが落ちる不具合が、GitHub issue #83467で報告されています。対話的なコマンドは影響を受けず、プロンプトを送信するストリーミング処理でだけ発生する、という切り分けが進んでいます。回避策として、npm経由のインストールへの切り替えと、動作報告のあるバージョンへの固定が共有されています。

症状と発生条件

最初の報告は、Mac mini M4上のParallelsで動くWindows 11 ARM64環境からのものです。Fable 5 Highでプロンプトを送信すると断続的にクラッシュし、「Claude Code process exited with code 3221225477」というエラーとともにセッションが落ちます。クラッシュ後の「フィードバックを送信」も「ヘルプを取得」も機能しません。

この報告を受けて検証した別のユーザーは、原因をより厳密に切り分けています。バンドルされた claude.exe は、Windows 11 ARM64上ではPrismエミュレーションで動くx64バイナリです。これをSDKストリーミングモード(Claude Desktopがローカルセッションで毎回使う実行モード)で起動すると、およそ30〜65%の確率で 0xC0000005 のアクセス違反を起こします。標準エラー出力は一切出ないまま落ちるため、原因追跡の手がかりがありません。

重要なのは、クラッシュが特定のモデルや特定のリクエスト処理に紐づいていない点です。何もリクエストを送らずstdinを閉じただけでも落ちるケースがあり、ストリーミングモードの起動・終了処理そのものに問題がある可能性を示しています。非ストリーミングのサブコマンドでは一件もクラッシュが確認されていません。同様の症状は本issue以前にも報告があり(#71765)、報告者によれば誤ってクローズされたとのことです。

自分の環境が該当するか切り分ける

0xC0000005 がストリーミング処理に限定されるかどうかは、次のコマンドで切り分けられます。

claude --version
claude doctor
claude mcp list

これらが正常に終了する一方で、次のコマンドだけが落ちるなら、本記事の不具合に該当する可能性が高いです。

claude -p "hi"

実際の再現テストでは、リクエストの送り方によってクラッシュ率が変わることも確認されています。

対処法

npm経由でインストールし直す

同一バージョンでも、ネイティブインストーラー(irm https://claude.ai/install.ps1 | iex)で入れたバイナリではクラッシュが100%再現し、npmでインストールした同一バージョンでは再現しなかった、という報告があります。まず試す価値があるのはこの切り替えです。

npm install -g @anthropic-ai/claude-code@latest

npmパッケージはNode.js 22以降を前提としますが、古いNode.jsでもEBADENGINE警告が出るだけでインストール自体は完了します。

動作実績のあるバージョンに固定する

同じ報告者は、2.1.111では claude -p "hi" が正常応答したのに対し、2.1.220と2.1.234では同じマシンで毎回クラッシュしたとしています。バージョンを固定して試す場合は次のように指定します。

npm install -g @anthropic-ai/claude-code@2.1.111

これはIntel製CPUのWindows 11 x64機での検証結果で、ARM64機での再現性は確認されていません。手元の環境で試したうえで判断してください。

WSL経由に切り替える

この不具合はWindows向けのネイティブバイナリのストリーミング処理に起因するとみられます。WSL上ではLinux向けバイナリが動くため、切り替えれば影響を受けない可能性があります。ネイティブ導入とWSL導入の判断材料はClaude Code Windowsインストールにまとめています。WSL環境でWindows側の管理設定を引き継ぐ挙動はwslInheritsWindowsSettingsの仕組みと設定方法で解説しています。

VS Code拡張の残留エントリを確認する

別の報告者は、VS Codeの統合ターミナルでClaude Codeを一度起動した直後から、あらゆる呼び出しでクラッシュするようになったとしています。該当のVS Code拡張(anthropic.claude-code)を削除し、バイナリを再インストールし、設定ファイルもリネームして初期状態に戻しても症状は消えませんでした。唯一残った痕跡は、~\.vscode\extensions\extensions.json に "pinned": true のまま残る拡張エントリです。本人もこれが原因かどうかは断定していませんが、心当たりがある場合は確認する価値があります。

なぜクラッシュするのか

0xC0000005 はWindowsのNTSTATUSコードで、メモリへの不正アクセス(アクセス違反)を意味する一般的な値です。終了コード 3221225477 はこれを符号なし32ビットで表した値、環境によって表示される -1073741819 は同じ値を符号付きで解釈したものです。

当初はARM64機のPrismエミュレーション(x64バイナリをARM64上で動かすWindowsの互換レイヤー)に特有の現象と見られていました。ところが、エミュレーションを介さないIntel製CPUのWindows 11 x64機でも同一のクラッシュが100%の確率で再現しており、Prismエミュレーション固有の問題という見立ては崩れています。

もう一つの手がかりは配布方式の違いです。同一バージョン・同一マシンで、ネイティブインストーラー由来のバイナリはクラッシュし、npm経由でインストールした同じバージョンのバイナリは正常に動いた、という報告があります。npmパッケージも最終的には同じネイティブバイナリを配置する仕組みですが、単一実行ファイル化(Node.jsのSEA機能)でビルドされたスタンドアロン版に固有の欠陥である可能性が、issue内では指摘されています。issueでは改善案として、ARM64ネイティブビルドの提供(またはx64エミュレーション経路の不具合調査)、フィードバック送信をクラッシュしたセッションから切り離すこと、子プロセスの標準エラー出力を記録することの3点が挙げられています。

クラッシュの影響範囲

ARM64機を検証した報告者のログでは、2026年7月26日から8月2日までの4日間で68件の関連する失敗が記録されていました。

ユーザーに見える「Claude Code crashed」ダイアログはこのうち6件だけで、残りはエージェント一覧やスラッシュコマンドの取得が裏側で静かに失敗しているだけの、見えない劣化です。Claude Desktopの「Code」タブは内部でこのストリーミングモードの claude.exe を起動しているため、同じ原因で「Claude Code crashed」と表示されます。同じマシンで動くCoworkは影響を受けていません。

診断をさらに難しくしているのが、クラッシュ後の情報収集経路がどちらも機能しないことです。フィードバック送信はクラッシュしたセッションの実行中クエリを前提とした設計のため、セッションが落ちた直後は送信できません。ログには2つのセッションにまたがる20回の送信試行が残っていますが、いずれも「session ... not found or has no active query」で拒否されています。子プロセスの標準エラー出力も記録されず、Windowsのクラッシュダンプ(WER)も生成されないため、Sentryが捕捉できるのは親プロセス側の「プロセスが終了した」というJavaScript例外だけで、実際の障害箇所に関する情報は残りません。

環境ごとの再現状況を整理すると、次のようになります。

Windows ARM64ネイティブ対応との関係

Claude CodeはWindows ARM64(win32-arm64)向けにプリビルドバイナリを公式に提供しており、サポート対象外のプラットフォームではありません。ただし今回の報告に含まれるバイナリのPE machine typeは 0x8664(x64)で、ARM64ネイティブではなくPrismエミュレーション経由で動いていました。ARM64ネイティブビルドが提供された経緯と、そのリリースでの他のWindows関連の変更はClaude Code v2.1.41にまとめています。Windows関連のクラッシュはこのissue以前にも修正されており、Claude Code v2.1.53では別系統の3種類のクラッシュに対応しています。

まとめ

issue #83467は2026年8月3日に報告され、直近のコメントは2026年8月18日です。対話コマンドは無事で claude -p や初回プロンプト送信だけが落ちる、という条件に当てはまるなら、まずnpm経由での再インストールを試し、それでも解決しなければバージョンを固定するか、WSL経由への切り替えを検討してください。VS Code拡張を一度でも使ったことがある場合は、拡張の残留エントリも確認しておくと切り分けが早くなります。