Claude Media
Claude CodeがARM64環境で固まる・SIGILLになるときの切り分け

Claude CodeがARM64環境で固まる・SIGILLになるときの切り分け

Orange Pi Zero 3では--versionだけ通って--helpが無出力で止まり、AndroidのAVFゲストではSVE命令でSIGILLになります。ARM64の2つの報告を症状で切り分けます。

Linux ARM64の小型ボードやAndroidのLinuxターミナルでClaude Codeを入れたら、出力がないまま固まる。Orange Pi Zero 3ではclaude --versionだけ通ってclaude --helpが無出力で止まり、AndroidのAVFゲストでは--versionすら返らず、Bunのバナーだけが出て止まります。

見た目はどちらも「固まる」ですが、報告されている中身は別物です。この記事では、GitHub issueの#98291と#101210を症状で切り分け、自分の環境がどちらに近いかを判断する手順を示します。確実な回避策はどちらもまだありません。

症状の違い

ARM64で固まる2つの報告

  • Orange Pi Zero 3(#98291)

    --versionは即時に返ります。--helpとagents系のコマンドは、timeoutで止めるまで無出力のままです。

  • AndroidのAVFゲスト(#101210)

    --versionでもインストーラーでも、Bunのバナーだけ出て止まります。直前にSIGILL(不正命令)を受けています。

Orange Pi Zero 3で、--helpだけが無出力で止まる

#98291は2026年9月30日に起票され、ラベルはbug・has repro・platform:linux・area:coreで、openのままです。報告された環境は次のとおりです。

項目値
ボード値Orange Pi Zero 3
OS値Ubuntu 24.04.4(arm64)
カーネル値6.1.31-sun50iw9(Allwinnerのベンダーカーネル)
glibc値2.39
CPU値Cortex-A53 ×4(最大1512MHz)
メモリ値3.8GiB、スワップ1.9GiB

試された版は2.1.220(npmとネイティブ)と、stableチャンネルの2.1.212です。2.1.220はnpm経由でもネイティブインストーラー経由でも、バイナリのSHA-256が同じだったと書かれています。つまり、インストール方法を変えても同じファイルが動いています。

症状は4つのコマンドで比較されています。いずれも新しいHOME、TTYなしで、TERM=dumb・NO_COLOR=1・CI=1・DISABLE_AUTOUPDATER=1を付けて実行した結果です。

コマンド結果
claude --version結果即時に終了コード0
claude --help結果無出力。終了コード137(SIGKILL)や124
claude agents --help結果無出力。終了コード124
claude agents --json --all --cwd <空のディレクトリ>結果無出力。終了コード124や137

終了コード124はGNU timeoutがSIGTERMで止めたことを、137はその5秒後もプロセスが生きていてSIGKILLを送ったことを表します。報告者は、収集時に約3.5GiBのメモリが空いていたため、メモリ不足で即座に殺された症状とは合わないと書いています。ヘルプやagentsのログは0バイトで、セッションログも作られていません。コマンドがセッションを開く前の段階で止まっているということです。

この報告から言えること、言えないこと

報告から読み取れるのは、--versionが通ってもバイナリが健全とは限らない、という点です。--versionは起動直後の軽い経路で終わるため、ヘルプ表示やagentsの初期化まで進んで初めて止まる環境があります。

一方で、原因までは特定されていません。報告者自身が「straceは取っていない」「ページサイズは記録していない」と書いています。測定は2026年8月2日で、ボードがオフラインのため新しいビルドでの再検証もされていません。起票時点の最新版で再現するかは、報告の中で未確認のままです。

報告者は関連する過去のissueを4件挙げ、どれとも違うと整理しています。

  • #58680: linux-arm64のベンダーカーネルで、--versionは通り、その後の起動が止まる。Jetson上の2.1.140で、closed
  • #62957: --versionそのものが止まる。今回は--versionが即時に返る
  • #35454: gVisor上のepoll_pwaitによる停止。このボードはgVisorではない
  • #25713: 64Kページのカーネルで即座に中断する。今回はプロセスが生き続けて何も書かない

AndroidのAVFゲストでは、SVE命令でSIGILLになる

#101210は2026年10月11日の起票で、こちらもopenです。環境はAndroidの「Linux Terminal」(Android Virtualization Frameworkのpkvmゲスト)で動くDebian 13、バージョンは2.1.296(linux-arm64)です。

症状は、インストーラーのinstallステップも、バイナリ直接実行の--versionも、次のバナーだけを出して止まる、というものです。

============================================================
Bun v1.4.3 (eecfd55de) Linux arm64

報告者はstraceとobjdumpで原因を追っています。

  1. 起動の早い段階でSIGILL(ILL_ILLOPC)を受ける。該当位置の命令は、SVE(Scalable Vector Extension)のcntb x8
  2. このゲストはSVEをユーザー空間向けに無効にしている。それなのにカーネルはSVE2とその拡張を広告している
  3. Bunのクラッシュハンドラーが動き出し、futex(..., FUTEX_WAIT, ...)で待ったままデッドロックする

2つ目の根拠として、AT_HWCAPのビット22(HWCAP_SVE)は立っておらず、AT_HWCAP2のビット1(HWCAP2_SVE2)は立っていた、という出力が載っています。/proc/cpuinfoのFeaturesにもsve2やsveaesはあるのに、sveはありません。

報告者の見立てでは、同梱のネイティブコードがCPU機能の検出でHWCAP_SVEではなくSVE2やIDレジスタの情報を信頼し、cntbを実行して落ちています。期待する挙動として、HWCAP_SVEが立っているときだけSVE系の経路を使いNEONへフォールバックすること、クラッシュしてもハンドラーがデッドロックせずに報告を出して終了することの2点が書かれています。

ここで大事なのは、画面上の「固まり」の正体がクラッシュハンドラーのデッドロックだという点です。ユーザーにはエラーが見えず、「インストールが固まった」ように見えます。同じ環境で動くChromium(V8)は正常で、VM全体が壊れているわけではない、とも書かれています。

類似の報告として#55519が先にあり、こちらはclosedです。タイトルには「v2.1.113で入った退行」とあります。#101210の本文は、この報告が自動クローズされたため新しく立て直した、と説明しています。

どちらに近いかを見分ける

2つの報告の違いは、「プロセスが何をしているか」にあります。報告された範囲では、Orange Pi側はstraceが取られておらず、AVF側はSIGILLからデッドロックまでが追えています。自分の環境で、まず同じ観測をしてみます。

手順1: 止まるまでの時間を区切って実行する

出力が出ないコマンドを手で待たずに、timeoutで区切ります。終了コードが分かれ目になります。

export TERM=dumb NO_COLOR=1 CI=1 DISABLE_AUTOUPDATER=1
timeout --signal=TERM --kill-after=5s 30s claude --version; echo "exit=$?"
timeout --signal=TERM --kill-after=5s 30s claude --help;    echo "exit=$?"

--versionが0で返り、--helpが124か137になるなら#98291と同じ型です。--versionが返らず、Bunのバナーが出るなら#101210と同じ型です。

手順2: straceで最後のシステムコールを見る

straceが入っていなければ、先に入れます。止まった状態でどのシステムコールに居るかが、原因の方向を決めます。

strace -f -o /tmp/cc.trace timeout 20s claude --version
grep -n -E "SIGILL|SIGSEGV|FUTEX_WAIT" /tmp/cc.trace | head

SIGILLの直後にFUTEX_WAITが続くなら、#101210と同型のクラッシュとデッドロックの組み合わせです。シグナルがなくずっと待っているだけなら、別の原因を疑うことになります。

手順3: SVEの広告と実際の可否を見る

SVEに関するカーネルの広告がちぐはぐになっていないかを確かめます。

LD_SHOW_AUXV=1 /bin/true | grep HWCAP
grep -m1 Features /proc/cpuinfo
getconf PAGESIZE

AT_HWCAPのビット22が立っていないのに、/proc/cpuinfoにsve2がある場合は、#101210と同じ状態です。getconf PAGESIZEは、64KBページが原因の#25713と見分けるために使います。#98291では、ページサイズが記録されていません。

公式のトラブルシュートが示す範囲

インストール関連の公式ページには、近い項目が3つあります。ただし、どれもこの2つの報告を直接は扱っていません。

公式の範囲

関連する公式の項目

  • Illegal instruction

    アーキテクチャの取り違えと、AVXを持たないCPUの2原因を説明します。uname -mとgrep -m1 -ow avx /proc/cpuinfoで確かめ、ネイティブバイナリの回避策はないとしています。

  • Killed(低メモリ)

    インストールには約512MBの空きメモリが必要で、実行にはそれ以上が必要です。スワップを足す手順が載っています。

  • バイナリの動作確認

    --versionは出るのに起動でクラッシュや停止が起きるときの手順です。ldd "$(command -v claude)" | grep "not found"で足りない共有ライブラリを調べます。

システム要件には「4GB以上のRAM、x64またはARM64のプロセッサー」とあります。#98291のボードはRAMが3.8GiBで、この数字を下回ります。ただ、報告では空きメモリが約3.5GiBあり、メモリ不足で殺された形跡はないと書かれています。要件との関係は報告者も言及していないため、RAM不足が原因と断定はできません。AVF側のIllegal instructionも、公式の2原因(アーキテクチャ違いとAVX欠如)のどちらにも当てはまりません。SVE命令の広告と実態のずれは、公式の項目の外にあります。

症状別の対処の目安

確実な回避策は報告されていないので、ここでは「何を確かめ、何を試せるか」の整理にとどめます。

症状まず確かめること試せること
--versionだけ通り、--helpが無出力まず確かめることメモリの空きとスワップ、timeoutの終了コード試せることスワップを足して再実行。issueへstraceを添える
バナーだけ出て止まる(AVF)まず確かめることstraceでSIGILLの有無、HWCAPの出力試せること修正版を待つ。環境の違うマシンで動かす
Killedと表示されて止まるまず確かめることfree -hで空き容量試せることスワップを足してインストーラーを再実行
Illegal instructionだけで止まるまず確かめることuname -mとAVXの有無試せることアーキテクチャに合うバイナリを入れ直す

AVFゲストの場合は、古いバージョンで動くかを試す価値があります。#101210は退行かという問いに「以前のバージョンでは動いた」と答えていますが、動いた最後のバージョンは記入されていません。#55519のタイトルは、v2.1.113で入った退行と述べています。それより前の版を固定する手順は、同じAndroid系のTermuxで動かない件の回避策にまとめた、バージョン固定の考え方が参考になります。ただしTermuxの失敗は別の原因で、そのままは当てはまりません。

issueに情報を足すときの項目

どちらの報告もopenで、コメントは0件です。同じ症状なら、次の項目を足すと原因の絞り込みに使われます。

  • uname -aと/proc/cpuinfoのFeatures行、getconf PAGESIZEの値
  • timeoutで区切ったコマンドの終了コードと、経過時間
  • strace -fのログのうち、最後の数十行と、SIGILLやSIGSEGVが現れる箇所
  • Claude Codeのバージョンと、npmかネイティブインストーラーかの区別
  • RAMとスワップの量、止まった時点の空きメモリ

ログに含まれるホームのパスやユーザー名は、置き換えてから貼ります。

似た症状との切り分け

ARM64のクラッシュは、症状が似ていても原因が別の報告が複数あります。

まとめ

ARM64で「固まる」ときは、--versionが通るかどうかと、止まる直前のシグナルで型が分かれます。Orange Pi Zero 3の報告は原因未特定の無出力ハング、AVFゲストの報告はSVE命令のcntbによるSIGILLとクラッシュハンドラーのデッドロックです。

まずtimeoutで区切って終了コードを取り、次にstraceでSIGILLの有無を見ます。この2手で、公式の対処が効く問題か、issueに情報を足す段階かが分かります。小型ボードでは、公式の要件にあるRAM 4GBを下回っていないかも、同時に確かめておく項目です。

この記事を共有:XはてブLinkedIn