Claude CodeがTermuxで動かない — native binary not installedの原因と回避策

このTipsでできること

Termux(Android上のLinux環境アプリ)でclaudeコマンドが「claude native binary not installed.」を出して起動しない場合の原因と、今も使える回避策を示します。

Claude Codeはv2.1.113からインストール方式を切り替えました。それ以前はNode.js製のcli.jsをnode経由で実行する方式でしたが、v2.1.113以降はプラットフォームごとのネイティブバイナリ(bin/claude.exe)を直接実行します。この切り替えがTermuxで破綻します。

エラーへの短い答えは次のとおりです。postinstallの失敗ではなく、AndroidにはClaude Code用のバイナリが配布されていないのが原因なので、案内どおりに再インストールしても直りません。バージョンを2.1.112に固定するか、proot-distroでLinuxゲストを動かすのが手数の少ない道です。glibcのglibc-runnerでネイティブ版を動かす方法もあります。

先に注意点を1つ。以前この種の回避策として紹介されていた@stableのdist-tagは、もう使えません。stableは2026年4月下旬には2.1.112を指していましたが、いまはネイティブ版の2.1.287を指します(npm registryの値)。

失敗は3段重なっている

Termuxで起きる失敗は、GitHub Issue #50270の報告とトラブルシューティングのページを突き合わせると、次の3段に分けて読めます。

3段目の拒否理由は、報告によって書き方が違います。Issue本文は「AndroidのカーネルがET_EXECのELFをunexpected e_type: 2で拒否する」としています。一方、9月22日のコメント(Android 9・カーネル4.19)では、生のバイナリはBunの起動処理がe_type: 2を拒否しました。e_typeを書き換えて通すと、今度はBionicのリンカーが「TLSセグメントのアラインメントが足りない(8、ARM64のBionicでは64以上が必要)」と拒否したそうです。

スタブのエラーメッセージも、Termuxでは原因を指しません。

Error: claude native binary not installed.
 
Either postinstall did not run (--ignore-scripts, some pnpm configs)
or the platform-native optional dependency was not downloaded
(--omit=optional).

この文面は--ignore-scriptsや--omit=optionalでバイナリが入らなかった場合の案内です。Termuxではpostinstallは正常に終わっており、対応するプラットフォームが無いだけなので、案内に従って再インストールしても同じ結果になります。Termux以外でこの文面が出た場合は、native binary not installedエラーの原因と対処を参照してください。

対応OSの範囲と、Anthropicの返答

システム要件に載っているOSは、macOS 13.0以降、Windows 10 1809以降またはWindows Server 2019以降、Ubuntu 20.04以降、Debian 10以降、Alpine Linux 3.19以降です。Androidはありません。

同ページは、ネイティブバイナリの欠落について次の2点を明記しています。

• 公開されているプラットフォームパッケージはdarwin-arm64 / darwin-x64 / linux-x64 / linux-arm64 / linux-x64-musl / linux-arm64-musl / win32-x64 / win32-arm64の8種類
• 上記以外にバイナリは配布されない

バイナリはオプション依存としてだけ配布されます。オプション依存をスキップした場合、JavaScriptのフォールバックはありません。

Issueには、Anthropicの担当者による2026年4月24日(JST)のコメントがあります。内容は次の4点です。

• 2.1.113はnpm非推奨の告知(1月)を受けてネイティブ実行ファイルへ切り替えた
• 一部のプラットフォームが非対応になる
• Androidは「将来追加するかもしれない」が、Bunのandroid-arm64ターゲットか静的musl版が必要
• 当面は最後のJSバンドルである2.1.112に固定できる

期限は示されていません。

回避策1 — 最後のJS版に固定する

もっとも手数が少ないのは、バージョンを2.1.112に固定する方法です。

npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code@2.1.112
claude --version

2.1.112はNode.js実行のcli.jsをbinに指定した最後のリリースです(npm registryで2.1.112はcli.js、2.1.113はbin/claude.exe)。9月22日のコメントでも、Termuxでこの版に固定して使っている報告があります。

@stableは選べません。npm view @anthropic-ai/claude-code dist-tagsでstable・latest・nextの指す先を見ると、いずれもネイティブ版です。固定は版番号で行います。

過去に@latestでインストールを試したことがあると、node_modules/@anthropic-ai/に未使用のプラットフォーム別パッケージが残ることがあります。Termuxのストレージを圧迫するので、固定の際に消しておけます。

NM=$(npm root -g)
for V in linux-arm64 linux-arm64-musl linux-x64 linux-x64-musl; do
  rm -rf "${NM}/@anthropic-ai/claude-code-${V}"
done

固定の代償は、機能の置いてけぼりです。7月10日のコメントは、公開版がv2.1.206の時点で2.1.112は94リリース分遅れており、v2.1.139以上を条件にする機能(リモート操作の経路)は固定中は使えないと指摘しています。

回避策2 — 自動更新を止める

固定しただけでは足りません。Issueには、2.1.112へ戻した数秒後に、起動中のClaude Code自身が最新版へ上書きし、cli.jsが消えたという報告があります。止める手段は2つあります。

案内されている方法は、settings.jsonのenvキーにDISABLE_AUTOUPDATERを入れることです。

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

説明では、この変数はバックグラウンド更新だけを止めます。claude updateとclaude installを含む全経路を止めるのはDISABLE_UPDATESです。

4月18日のコメントによると、DISABLE_AUTOUPDATER=1を付けて2.1.112を入れ、さらにインストール先のディレクトリから書き込み権限を外して(chmod -R a-w)初めて固定が保てたとされています。更新の書き込みが静かに勝つため、とのことです。ただし書き込み権限を外すと、のちにバージョンを上げたいときに権限を戻す手間が出ます。

Issueのコメントには"autoUpdates": falseをsettings.jsonに書く方法も出ています。ただし公式に説明があるのは、設定キーではなく環境変数のDISABLE_AUTOUPDATERのほうです。4月18日のコメントは、この変数だけでは上書きを止めきれなかったとして、更新側がDISABLE_AUTOUPDATER=1に従うよう求めています。settings.jsonの他の項目はClaude Code設定ガイドにあります。

回避策3 — proot-distroでLinuxゲストを動かす

Termuxのproot-distroでUbuntuなどを起動すると、ゲストの中ではprocess.platformがlinuxになり、ネイティブ版がインストールされます。Issue本文でも「proot-distroなら動くが対話利用には遅い」とされています。

pkg install proot-distro
proot-distro install ubuntu
proot-distro login ubuntu -- apt update
proot-distro login ubuntu -- apt install -y nodejs npm
proot-distro login ubuntu -- npm install -g @anthropic-ai/claude-code
proot-distro login ubuntu -- claude --version

ゲストのUbuntu側にNode.js(npm)が必要なので、先に入れておきます。

最新版まで動くとは限りません。6月21日のコメントは、prootでも2.1.185でBunのクラッシュ(bun#32489)に当たったと報告しています。Bunは報告されたカーネルが5.11以上だとepoll_pwait2を使う仕様で、同じ投稿者の同日の別コメントにある対処がproot -k 5.10.0で古いカーネル番号を名乗らせる方法です。その後、prootなしで2.1.185が動いたという6月22日のコメントも出ています。ゲストのUbuntu側でパッケージ依存のエラーが出た場合は、Claude Code Ubuntuインストールが参考になります。

回避策4 — glibc-runnerで現行のネイティブ版を動かす

最新のネイティブ版を直接動かす方法もあります。Issueで共有されている手順は、Termuxのglibc-packagesリポジトリのglibc-runnerとpatchelf-glibcを使い、バイナリのELFインタープリタをglibc互換のローダーへ書き換えます。LD_PRELOADを空にして起動し、実行前に公式manifest.jsonのSHA256と照合することも前提です。

5月から6月にかけては、この作業をまとめたスクリプトや、コミュニティ製のdebパッケージがIssue内で共有されています。Issueには次の運用報告があります。

• 2.1.185、2.1.207、2.1.280が、この系統の構成でTermux上で動いた(6月・7月・9月のコメント)
• termux-execは2.4.0以上でdebがそのまま使え、F-Droid版の既定である1.9系では追加の対処が必要(6月23日のコメント)
• ネイティブ版にはDNSの癖があり、Bunのc-aresが絶対パスの/etc/resolv.confを読むため、AndroidではWebFetchやMCPが失敗する(6月27日のコメント。コミュニティ製ランチャー側で7月までに回避が入った。7月10日・11日のコメント)
• settings.jsonのenvにLD_PRELOADを入れたままだと、同梱のgrep・findがinvalid ELF headerで動かなくなります。外すとgrep・findは動く代わりに、Node・Pythonのshebangスクリプトが動かなくなります(5月30日・6月1日のコメント)

非公式の構成なので、Anthropic側のELFやBunの変更で壊れうる点は、報告者自身も認めています。

同じ手順が端末によって通らない

回避策4は、端末によって結果が割れます。Issue内の報告を端末ごとに並べると、境目はAndroidのバージョンより端末側にあるように見えます。

Fold5とS23 Ultraはどちらも5.15.x-android13-8のカーネルで、PT_INTERP(ELFが指定するローダー)を尊重するかどうかが違いました。原因が端末のROMなのか、パッチの範囲なのかは、Issue内でも決着していません。手順を踏んでもBionicのエラーが出るときは、固定(回避策1・2)かprootに切り替える判断になります。

恒久対応の見通し

Issueで挙がっている解決案は3つです。

• android-arm64向けにBionic互換、または静的リンクのバイナリを公開する
• cli.jsを、エラーを出すだけでなく実際に動くフォールバックとして残す
• process.platformがandroidのときにlinuxとして扱う(glibcで動かない問題は別に残る)

3つめの案の前提として、Issueの投稿者が指摘しているのは、install.cjsとcli-wrapper.cjsにlinux-arm64-androidへの言及が既にあり、欠けているのはビルド済みのバイナリだという点です。ただしトラブルシューティングが列挙する8パッケージに、このパッケージはありません。Anthropicからの採否の返答は、4月24日(JST)のコメント以降、Issueに出ていません。

どの回避策を選ぶか

回避策4が手元の端末で通るかどうかは、strace -f -e execveでパッチ後のELFが直接実行されるか、/system/bin/linker64に回されるかを見ると見当がつきます。端末比較のコメントでも、この確認が分かれ目になっていました。回されるなら、2.1.112の固定(回避策1・2)かprootが現実的です。OS別のインストール手順全般はClaude Code install完全ガイドに載せています。