Claude CodeがVirtualBoxでGeneral Protection Faultになる原因

VirtualBoxのゲストでClaude Codeを動かすと、claude --versionすら通らずに落ちる。GitHub issue #80308は、そんな報告です。カーネルのログにはgeneral protection faultが残ります。issueはopenで、原因も修正バージョンも確定していません。

分かっているのは、報告者たちが何を見て、何を試したかです。そこから「AVXが見えていないから」という定番の説明だけでは足りないことが読み取れます。

報告された環境と症状

issueの題名は「Kubuntu 26.04」ですが、本文の環境欄は「Ubuntu Server LTS 26.04 minimal」と書いています。どちらのデスクトップ環境でも、起きていることは同じです。

最初の報告者は、前日にインストーラーで入れて普通に使えていました。セッションIDを控えて正常にシャットダウンし、翌日に再開しようとして落ちたそうです。claude --resumeだけでなく、--version、--help、引数なしのclaudeもすべて同じ落ち方をしました。

~/.claudeを退避して初期状態にしても変わりません。xtermなど別の端末でも同じでした。設定や端末のせいではありません。

dmesgに出るログの読み方

カーネルログには、次の行が残ります。

traps: claude[2144] general protection fault ip:30497b0 sp:7ffd4666fea0 error:0 in 2.1.217[2e487b0,1b30000+371f000]

読みどころは3つです。

• general protection fault: CPUが命令の実行そのものを拒否した
• ip:30497b0: 落ちた命令の位置。複数回の起動で同じ値
• in 2.1.217[...]: 落ちた場所がClaude Codeのバイナリ内であること

別の報告者(Windows 11ホスト、Intel CPU)は、2.1.219でもip、コード開始位置、マッピングの基点とサイズがすべて一致した行を貼っています。2.1.217から2.1.219の間で、落ちる位置は動いていません。

最初の報告者は、複製した別のVMでは別のログも見ています。

claude[2151]: segfault at 180 ip 0000000000000180 sp 00007ffe5898bfe8 error 14
Code: Unable to access opcode bytes at 0x156.

こちらは存在しない番地へ飛んだ型で、general protection faultとは出方が違います。同じ症状でも、ログが2種類出る点は、原因を一つに決めつけにくい材料です。

strace上は起動の最初期で落ちている

追加報告者のstraceでは、落ちるまでに見えるのはローダーとglibcの初期化だけでした。ライブラリのmmap、arch_prctl、set_tid_address、rseq、mprotect、getrandom、futexといった呼び出しが並び、そのあとシグナルです。

--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++

設定ファイルを開く前、ネットワークに触れる前に落ちます。つまりログイン状態やプロジェクトの中身とは無関係です。si_code=SI_KERNELでsi_addr=NULLの組み合わせは、未割り当てページへのアクセスではなく、CPUが命令を拒否したときの形で、dmesgのGPFと整合します。

AVX説だけでは説明できない

Claude Codeのネイティブバイナリが使うCPU命令に、AVXが含まれます。公式のインストール障害対応は、Illegal instructionの原因の一つにこの点を挙げ、「ハイパーバイザーがAVXをゲストに渡さない仮想マシン」を含めています。確認は次の1行です。

grep -m1 -ow avx /proc/cpuinfo

何も出なければ、AVXはゲストに見えていません。issueのコメントにも「VirtualBoxは既定でAVXをゲストに渡さないから落ちる」という説明があります。

ところが、このissueの2人の報告者は、どちらもゲストのflagsにavxとavx2が見えています。追加報告者はgrep -om1 -E 'avx2|avx|sse4_2'の出力を貼り、CPU lacks AVX supportの表示も出ていないと書いています。症状もSIGILL(不正命令)ではなくSIGSEGVです。

整理すると、AVX説が当てはまる環境と、当てはまらない環境があります。

一般的なIllegal instructionの切り分けは、Illegal instructionエラーの原因と対処で扱っています。本件はその手前の確認(grep avx)を通ったうえで落ちる点が違います。

出ている仮説を並べる

issue内で挙がった仮説は3つです。いずれも、報告者の推測の域を出ていません。

XSAVEの仮説を出した追加報告者自身も「推測」と断っています。スナップショットの仮説を出した報告者は、スナップショットが1つ以上あるVMを再起動したあとにだけ、opencodeなど別のBunバイナリでも落ちると書いています。

どれが正解かはissueから決まりません。確実なのは、flagsの見え方だけでは切り分けられないということです。

バイナリのサイズが違っていた件

最初の報告者のコメントに、見逃せない観察があります。落ちるユーザーと動くユーザーで、同じ2.1.217のファイルサイズが違ったのです。

動くほうのファイルを落ちるほうへコピーして上書きすると、動くようになったと書かれています。同じバージョン番号なのにサイズが違う理由は、報告者も「分からない」と述べています。

ここから次の筋書きが考えられます。どちらも推測ですが、手元で検証できます。

• ダウンロードやディスク書き込みの途中でファイルが壊れた
• 配布物と別のファイルがディスクに置かれていた(経緯は不明)

サイズが違う時点で、少なくとも2つのファイルは同一ではありません。ファイルが正しいかどうかは、公式が手順を示しているマニフェストのSHA256で調べられます。

手元でできる切り分けの順番

まず、いまのファイルが正しいかを確かめます。

マニフェストと照合する手順は、公式のセットアップ手順に載っています。インストール済みのバイナリは~/.local/share/claude/versions/以下にあるので、そのファイルに対して実行します。

REPO=https://downloads.claude.ai/claude-code-releases
VERSION=2.1.217
curl -fsSLO "$REPO/$VERSION/manifest.json"
sha256sum ~/.local/share/claude/versions/$VERSION
grep -n checksum manifest.json

manifest.jsonのplatforms.<platform>.checksumとsha256sumの出力を見比べます。マニフェストの署名検証(gpg)は公式手順の1〜3にあり、2.1.89以降のリリースが対象です。ここでは、ファイルが壊れていないかを見るだけなら照合だけで足ります。checksumは複数の行に出るので、自分のプラットフォームの行を選びます。

ファイルが壊れていたら、バージョンを指定して入れ直します。

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.217
claude --version

インストールが完了すると、claude --versionでバージョンが出ます。入れ直しても同じ位置(ip:30497b0)で落ちるなら、ファイルの破損ではありません。

回避策として挙がったもの

issueのコメントに出た回避策は4つです。どれも公式の対処ではなく、効果が確認されたとは限りません。

フォークについては、コメントの作者自身が「バージョン番号は上流に合わせているが、アプリ本体のコードは2.1.88の時期で止まっている」と説明しています。インストールはcurlでスクリプトを取得してそのまま実行する形です。公式の機能追従や修正は受けられません。仕事で使うマシンに入れる前に、中身を読めるかどうかを基準にしてください。

ホスト側のCPUやVirtualBoxの設定を変える方法は、報告者の環境がAVX可視のため、効くかどうかは分かりません。

報告に添えると役立つ情報

issueはまだopenで、情報が増えるほど原因に近づきます。次を添えるとよいでしょう。

uname -r
grep -m1 "model name" /proc/cpuinfo
grep -m1 -ow avx /proc/cpuinfo
sudo dmesg | grep "general protection"
ls -la ~/.local/share/claude/versions/
sha256sum ~/.local/share/claude/versions/*

加えて、VirtualBoxのバージョン、VMにスナップショットがあるか、ホストOS、CPU世代を書きます。公式のIllegal instruction向けの案内も、報告時にgrep -m1 "model name" /proc/cpuinfoの結果を含めるよう求めています。

起動時のクラッシュはVirtualBoxに限りません。Ubuntu 26.04でBunが落ちる別の報告はClaude CodeのUbuntu 26.04 segfaultに、glibc側の原因はClaude CodeがSIGSEGVで起動直後にクラッシュする原因と対処法にあります。症状が似ていても、ipが固定か、bun.reportのURLが出るかで見分けられます。

まとめ

このissueが示すのは、「AVXが見えているのに落ちる」VirtualBoxゲストが少なくとも2つ報告されている、という事実です。AVXの確認は最初に行う価値がありますが、結果が「見えている」でも安心できません。

次の一手は、バイナリのSHA256をマニフェストと照合することです。同じバージョンでサイズが違うという観察は、ファイルの破損を疑える具体的な手がかりになります。照合が一致するなら、スナップショットの有無とVMのCPU設定を比べる段階です。