Claude CodeがTermuxで動かない理由 — glibcネイティブ移行の影響と回避策
Claude CodeがTermux(Android)で起動しない原因は、v2.1.113からのネイティブバイナリ移行です。root原因と暫定回避策を示します。
このTipsでできること
Termux(Android上のLinux環境アプリ)でclaudeコマンドが「claude native binary not installed.」を出して起動しない場合の原因と、現実的な回避策を示します。
Claude Codeはv2.1.113からインストール方式を切り替えました。それ以前はNode.js製のJavaScriptファイル(cli.js)をnode経由で実行する方式でしたが、v2.1.113以降はプラットフォームごとのネイティブバイナリ(bin/claude.exe)を直接実行する方式です。この切り替えがTermuxで例外的に破綻します。
移行の背景 — なぜネイティブバイナリ化したのか
Claude Codeは以前、npm経由でのグローバルインストールに関する非推奨(deprecation)通知を出していました。v2.1.113のネイティブバイナリへの切り替えは、この通知に沿った変更です。Android対応の再開には「Bun向けのandroid-arm64ターゲット」か「静的リンクのmuslビルド」のいずれかが必要です。対応の見通しは示されていません。JavaScript実行に依存しないネイティブバイナリ化は、起動速度の改善やNode.jsランタイムの同梱不要化を狙った変更です。一方で、Node.jsさえあれば動いていた旧方式に依存していたプラットフォーム(Termux/Android、Haiku OS、OpenBSD等)を切り捨てる副作用を伴いました。
なぜTermuxで起動しないのか
原因は3つ重なっています。いずれもGitHub Issue #50270で報告・検証されたものです。
1. process.platformがandroidを返す
Termux上のNode.jsでprocess.platformを評価すると"android"が返ります。Claude Codeのインストーラー(install.cjs)はこの値をプラットフォーム判定キーに使いますが、対応表(PLATFORMS)にandroid-arm64のエントリは存在しません。該当エントリがないとinstall.cjsはエラーを出さずにreturnし、npmはインストール成功のままバイナリなしの状態で終わります。
2. Android(Bionic libc)はglibcネイティブバイナリを実行できない
ネイティブバイナリはglibc(GNU C Library)向けにビルドされています。AndroidはBionic libcを使い、glibc向けのELFバイナリ(ET_EXEC形式)をunexpected e_type: 2のエラーで拒否します。linux-arm64-muslパッケージで回避しようとしても、musl版は動的リンクでmuslのローダー(ld-musl-aarch64.so.1)を要求するため、Bionic環境では同様に実行できません(required file not found)。
3. スタブのエラーメッセージが実際の原因と食い違う
バイナリが未配置のままclaudeを実行すると、次のスタブメッセージが表示されます。
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).このメッセージは「postinstallが実行されなかった」ケース向けの案内です。Termuxではpostinstall自体は正常に完了しており、単に対応プラットフォームが存在しないだけなので、メッセージに従って再インストールしても同じ結果になります。同じエラーメッセージでもmacOS・Linuxでの主な原因(--omit=optional等のフラグ)は別物なので、Termux以外の環境で発生した場合はnative binary not installedエラーの原因と対処を参照してください。
公式のサポート対象プラットフォームに含まれない
Claude Code公式ドキュメントのシステム要件では、対応OSとして次が明記されています。
- macOS 13.0以降
- Windows 10 1809以降またはWindows Server 2019以降
- Ubuntu 20.04以降
- Debian 10以降
- Alpine Linux 3.19以降
npmインストールで公開されているプラットフォームパッケージはdarwin-arm64 / darwin-x64 / linux-x64 / linux-arm64 / linux-x64-musl / linux-arm64-musl / win32-x64 / win32-arm64の8種類のみです。Android(Termux)はこのいずれにも該当しません。
回避策1 — 最後のJS版にピン止めする
最も確実な回避策は、ネイティブバイナリ移行前の最終版にバージョンを固定することです。
npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code@2.1.112
claude --version2.1.112はNode.js実行のcli.jsをbinに指定した最後のリリースで、Termux上でも正常に動作します。バージョン番号を直接指定する代わりに、@stableのdist-tagを使う方法もあります。2026-04-25時点でstableタグは2.1.112を指しており、2.1.112が将来unpublishされた場合や2.1.112.xのパッチが出た場合にも追従できる利点があります。
npm install -g @anthropic-ai/claude-code@stabledist-tagの指し先はリリースのたびに変わり得るため、実行前にnpm view @anthropic-ai/claude-code dist-tagsで現在の対応関係を確認してください。
過去に一度でも@latestでインストールを試みていた場合、node_modules/@anthropic-ai/配下に未使用のプラットフォーム別パッケージ(claude-code-linux-arm64等)が複数残っていることがあります。放置すると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回避策2 — 自動更新を止める(必須)
バージョンをピン止めしただけでは不十分です。Claude Codeにはセッション中に自動更新を試みる仕組みがあり、手動で2.1.112に戻した直後に自動更新が走り、数秒〜数時間でネイティブバイナリ版へ巻き戻されるケースが複数報告されています。~/.claude/settings.jsonに次を追加し、自動更新を無効化してください。
{
"autoUpdates": false
}環境変数DISABLE_AUTOUPDATER=1を併用する方法もあります。設定ファイルの変更だけでは自動更新の書き込みに負けるケースがあり、インストールディレクトリの書き込み権限を外す追加策も紹介されています。ただしこの方法は、以降のバージョンアップ時に権限を戻す手間が発生する点に注意してください。settings.jsonの他の設定項目についてはClaude Code設定ガイドにまとめています。
回避策3 — proot-distro経由でLinux環境をエミュレートする
Termuxのproot-distroでUbuntu等のLinuxゲストを起動すれば、ゲスト内のprocess.platformはlinuxを返すため、ネイティブバイナリ版がそのまま動作します。動作は確認されていますが、エミュレーション層を挟む分、対話利用には重いという指摘もあります。ゲスト内ではprocess.platformが常にlinuxと判定されるため、今後Anthropic側が対応プラットフォームの構成を変えても影響を受けにくいという特性もあります。ゲスト側のUbuntu環境自体でパッケージ依存関係のエラーに当たった場合はClaude Code Ubuntuインストールが参考になります。
pkg install proot-distro
proot-distro install ubuntu
proot-distro login ubuntu -- bash -c "npm install -g @anthropic-ai/claude-code && claude --version"回避策4 — 現行バージョンのネイティブバイナリをTermux上で強制実行する
Issue内でgtbuchanan氏が報告している手順では、glibc-runnerとpatchelf-glibc(いずれもTermuxのglibc-packagesリポジトリで配布)を使い、ネイティブバイナリのELFインタープリタをglibc互換のローダーに書き換えて直接実行します。バイナリをパッチし、チェックサムを検証し、LD_PRELOADを制御したうえで専用ラッパーをコンパイルする必要があり、リリースのたびに再実行が必要です。仕組みが複雑で、バージョンアップごとの保守コストがかかるため、回避策1・2で足りるなら優先度は下がります。ダウンロードしたバイナリを実行前に公式manifest.jsonのSHA256チェックサムと照合する工程を省かないことが、この方法を安全に使う上での前提です。
恒久対応は提案されているか
Issueでは、根本的な解決策として次の3案が挙げられています。
android-arm64向けにBionic libc互換の静的リンクバイナリを追加するcli.js(旧JS版)を、エラーメッセージを出すだけでなく実際に動くフォールバックとして残すprocess.platformがandroidを返すケースをlinuxとして扱う(ただしglibc実行不可の問題は別途残る)
いずれも提案段階で、採用が決まったものはありません。提案の主眼は「Androidを公式サポート対象に加える」ことではなく、「対応バイナリが存在しないプラットフォームでは、以前まで動いていたJS版へ自動的にフォールバックする」という小規模な変更です。実現すれば、Termux/Androidに限らずHaiku OSやFreeBSDなど、今後プリビルドバイナリが用意されない環境でも同じ恩恵を受けられます。Termuxはモバイル環境でClaude Codeを動かす数少ない手段のひとつで、この状態が続く限り、Android上のユーザーはアップデートから取り残されたままになります。
4つの回避策の使い分け
| 回避策 | 手間 | 最新機能への追従 | 向くケース |
|---|---|---|---|
JS版ピン止め(@2.1.112または@stable) | 手間低 | 最新機能への追従できない(2.1.112相当で停止) | 向くケースまず試す・恒久ではなく暫定運用 |
| 自動更新の無効化 | 手間低 | 最新機能への追従— | 向くケース回避策1と必ずセットで実施 |
| proot-distro経由 | 手間中 | 最新機能への追従可能(Linuxゲスト内で最新版) | 向くケースパフォーマンス低下を許容できる |
| ネイティブバイナリのパッチ実行 | 手間高 | 最新機能への追従可能(手動更新のたび再作業) | 向くケース最新版の速度・機能を維持したい上級者 |
まとめ
TermuxでClaude Codeが動かないのは、v2.1.113以降のネイティブバイナリ移行によって、Bionic libc環境(Android)向けのバイナリが存在しないためです。恒久的な公式対応が出るまでは、JS版へのピン止め(@2.1.112または@stable)と自動更新の無効化を組み合わせるのが、手間と安定性のバランスが取れた選択です。OS別のインストール手順全般はClaude Code install完全ガイドで確認できます。