Claude CodeのWindows ARM64で3221225477(0xC0000005)が出る原因と対処

「Claude Code process exited with code 3221225477」と表示されたら、0xC0000005(アクセス違反)で claude.exe が落ちています。Windows ARM64機だけでなくx64機でも起きる不具合で、GitHub issue #83467で報告されています。ClaudeはWindows ARM64向けのバイナリを公式に提供していますが、報告されたバイナリはx64版をPrismエミュレーションで動かしたものでした。対話的なコマンドは影響を受けず、プロンプトを送信するストリーミング処理でだけ発生する、という切り分けが進んでいます。このissueは2026年10月2日に、公式の修正が示されないまま「長期間更新がない」ことを理由に not planned で閉じられました。回避策として、npm経由のインストールへの切り替えと、動作報告のあるバージョンへの固定がコメントで共有されています。

症状と発生条件

最初の報告は、Mac mini M4上のParallelsで動くWindows 11 ARM64環境からのものです。環境欄にはClaude Desktop 1.24012.9(2026-07-24のビルド)のCodeタブとあります。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)、報告者によれば誤ってクローズされたとのことです。

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

issueの再現手順は、--print に --input-format stream-json と --output-format stream-json を組み合わせた起動です。v2.1.287の claude --help では、この2つのオプションは --print と一緒に使うものとして説明されています。入力形式は既定が text で、stream-json を選ぶとリアルタイムのストリーミング入力になります。claude -p "hi" はこの組み合わせではありませんが、報告者の環境では同じく落ちています。

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

対処法

どの対処が効きうるかは、症状が出る場所で変わります。Ubuntu 26.04で起動直後に落ちる場合は、Bunのsegfault報告の切り分けも参考になります。

Desktopが起動するのは、アプリに同梱された %APPDATA%\Claude\claude-code\2.1.219\claude.exe のようなバイナリです。npmで入れた claude とは別のファイルなので、CLI側を入れ替えてもCodeタブの挙動は変わらない可能性があります。

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

同一バージョンでも、ネイティブインストーラー(irm https://claude.ai/install.ps1 | iex)で入れたバイナリではクラッシュが100%再現し、npmでインストールした同一バージョンでは再現しなかった、という報告があります。ただし、npm側で動いたと確認されているのは2.1.111だけで、最新版で同じ結果になる保証はありません。

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

npmパッケージはNode.js 22以降が前提です。古いNode.jsでは EBADENGINE の警告が出ますが、インストールは完了し claude も動きます。2.1.113以降のパッケージが取ってくるネイティブバイナリは、実行時にNode.jsを使わないためです。

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

同じ報告者は、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機の報告ではありません。2.1.111は、CLIがネイティブバイナリを起動する方式に変わった2.1.113より前のバージョンで、バンドルされたJavaScriptがNode.js上で動く構成でした。

固定したバージョンは、放っておくと更新されます。ネイティブ導入は自動でバックグラウンド更新され、書き込み権限のあるnpmグローバル導入でも自動更新の対象になります。settings.json の env に次を書くと、バックグラウンド更新だけが止まります。

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

claude update と claude install は止まりません。手動更新まで止めるなら DISABLE_UPDATES を 1 にします。minimumVersion は下限を決める設定で、古いバージョンを固定する用途には使えません。

WSL経由に切り替える

WSLで試した報告はissueにありません。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経由の同じバージョンは正常に動いたという報告があります。ただし、その理由づけは報告者のコメントと公式ドキュメントで食い違っています。

2.1.113未満のnpm版はJavaScript版で、それ以降は公式の記述どおりネイティブバイナリです。報告された2.1.111はJavaScript版なので、報告者の見立てどおりNode.jsで動いた差が出た可能性があります。一方、2.1.113以降のnpm版で動いた報告はなく、最新版へ入れ替えて直る保証はありません。実証済みの回避策は、2.1.111のnpm導入です。

issueでは改善案として、ARM64ネイティブビルドの提供(またはx64エミュレーション経路の不具合調査)、フィードバック送信をクラッシュしたセッションから切り離すこと、子プロセスの標準エラー出力を記録することの3点が挙げられています。

クラッシュの影響範囲

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

ユーザーに見える「Claude Code crashed」ダイアログはこのうち6件だけで、残りはエージェント一覧やスラッシュコマンドの取得が裏側で静かに失敗しているだけの、見えない劣化です。Claude Desktopの「Code」タブは内部でこのストリーミングモードの claude.exe を起動しているため、同じ原因で「Claude Code crashed」と表示されます。x64機の報告では、同じマシンの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エミュレーション経由で動いていました。npmパッケージの対応プラットフォームにも win32-arm64 が入っており、ARM64向けのネイティブ版は別の配布物として存在します。ARM64ネイティブビルドが提供された経緯と、そのリリースでの他のWindows関連の変更はClaude Code v2.1.41にまとめています。Windows関連のクラッシュはこのissue以前にも修正されており、Claude Code v2.1.53では別系統の3種類のクラッシュに対応しています。

issueのその後と、読者が持ち帰る判断

閉じられたことは、不具合が直ったことを意味しません。同じ症状に当たったら、新しいissueで報告し直す形になります。そのときは、claude -p "hi" の結果、インストール方法、バージョンを添えると切り分けが進みます。

回避策は報告ベースです。実証されているのはnpmの2.1.111とMicrosoft Store版Desktopで、WSLは未検証です。まず claude -p "hi" で落ちるか確かめ、落ちるなら実証済みの手から試す形になります。