Claude Codeが起動直後にSIGSEGVで落ちる——glibc 2.44とmimallocの干渉バグをGitHub Issueで追った

エンジニアのゆとです。

Arch LinuxやCachyOSでClaude Codeをアップデートしたら、claudeどころかclaude --versionすら実行できなくなった——という報告が2026年8月下旬に立て続けに来ていた。エラーメッセージすら出ない。ターミナルに一瞬何か表示されたと思ったら、シェルがSegmentation fault (core dumped)とだけ返して終わる。

claude 起動しないで検索すると出てくる情報はほぼ全部Windowsのcommand not foundかPATHの話で、Linuxのネイティブインストールがバイナリレベルでいきなり死ぬケースはほとんど触れられていない。今回はGitHub Issueに集まった十数件の実測データをもとに、何が起きていたのかを技術的に追ってみる。

まず結論——glibc 2.44環境のv2.1.242/2.1.243は即アップデートかダウングレードで回避する

対象はNode.jsのClaude Codeではなく、ネイティブインストール版（~/.local/share/claude/versions/配下のバイナリ）。影響を受けるのは以下の組み合わせだ。

• Claude Codeバージョン: 2.1.242 または 2.1.243
• OS: Arch Linux、CachyOS、Fedora Rawhide、Manjaro（rolling）などglibc 2.44系を使うディストリビューション
• 症状: claude --versionを含むすべての起動が100%の確率でSIGSEGV（シグナル11）でクラッシュ、エラーメッセージは一切出ない

今すぐ復旧したい場合の選択肢は2つ。

# 選択肢1: 最新版に更新（2.1.245以降で修正済み）
claude update

# 選択肢2: 一時的に前のバージョンへ symlink を張り直す
ls ~/.local/share/claude/versions/
ln -sf ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude

2.1.245で修正が入っているので、claude updateが実行できる状態ならそれだけで直る。問題は「claudeコマンド自体が起動できないのでclaude updateも打てない」ケースで、その場合は一時的に旧バージョンへのシンボリックリンクを張り直す方法が唯一の回避策になる。

Aug 15, 2026 Claude Codeを前のバージョンに戻す方法——ダウングレードと`claude install`、二度と壊れないためのバージョン固定Claude Codeがアップデート後に不安定になったときの戻し方を解説。claude installコマンドでの特定バージョンへの切り替え、npm/Homebrew別の手順、autoUpdatesChannelとminimumVersionでの固定、ダウングレードすべきか迷ったときの判断基準までまとめた。読む →

何が起きていたか——バイナリ差分で原因を追う

このバグが厄介だったのは、症状からは原因がまったく読めない点だ。設定ファイルもプロジェクトも関係なく、素の--versionですら落ちる。GitHub Issueで最初に報告されたのは2026年8月24日、複数のユーザーが独立に同じ現象を再現し、数時間のうちに根本原因まで特定された。

症状: バージョンを1つ戻すだけで直る

報告者が最初に確認したのは、隣り合うバージョンでの挙動差だった。

2.1.239: exit=0
2.1.240: exit=0
2.1.241: exit=0
2.1.242: exit=139（SIGSEGV）

同じマシン、同じシェル、同じglibcで、2.1.242に上げた瞬間だけ死ぬ。設定やプロジェクトが原因ではなく、バイナリそのものに問題があることがこの時点でほぼ確定した。

原因: mimallocがglibcのアロケータ関数を「乗っ取って」いた

readelf --dyn-symsでエクスポートされているシンボルを比較すると、2.1.242からmalloc/free/calloc/realloc/aligned_alloc/posix_memalignが新たにグローバル公開されていた。

$ readelf --dyn-syms --wide 2.1.241 | grep -E '\b(free|malloc|calloc)\b'
# 出力なし

$ readelf --dyn-syms --wide 2.1.242 | grep -E '\b(free|malloc|calloc)\b'
   560: 0000000001d10320   145 FUNC GLOBAL DEFAULT 17 calloc@@GLIBC_2.2.5
   700: 0000000001d102d0    79 FUNC GLOBAL DEFAULT 17 malloc@@GLIBC_2.2.5

これはClaude Codeが内部で使っているメモリアロケータmimallocが、プロセス全体のmalloc/freeを「差し替える」形でバンドルされたことを意味する。ここまでは高速化のための一般的な最適化手法で、それ自体はおかしくない。

問題は差し替えたfreeの実装だ。C言語の規格（C17 7.22.3.3p2）ではfree(NULL)は何もしないno-opであることが保証されている。ところがmimallocが提供するfreeにはこのNULLチェックが抜けていた。

そしてglibc自身が、プロセス起動のごく初期にnewlocale()を呼ぶ過程でfree(NULL)を実行する。通常のglibc標準freeならここで何も起きずに素通りするが、mimalloc製のfreeに差し替わっていたせいでNULLポインタを実際に参照しにいってクラッシュする——という流れだった。

#0  free ()              ← claudeバイナリ内のmimalloc製free
#1  newlocale ()         ← glibcの起動処理
#2  ??
#3  ??  from libc.so.6
#4  pthread_once ()
...
#16 __libc_start_main ()

%rdi（第一引数）レジスタが0になった状態でfreeに入っていることも複数の報告者がgdb/coredumpctlで確認しており、「NULLを渡されたfreeがそのまま処理を続けてしまう」という診断と一致する。

なぜ「glibc 2.44だけ」で起きるのか

ここが一番実務的に重要なポイントだ。同じ2.1.242/2.1.243バイナリでも、Debian 12、Ubuntu 24.04/24.10/25.04/25.10、Fedora 44では問題なく動く。クラッシュするのはglibc 2.43.9000（Fedora Rawhide）以降、特に2.44（Arch Linux、CachyOS）に限られる。

つまりバグの引き金はClaude Code側の変更（mimallocのシンボルエクスポート）だが、実際にクラッシュを引き起こすかどうかはglibc側のnewlocale実装の変化に依存していた——「新しいバージョンにしたら壊れた」の犯人がアップデートしたアプリとは限らない、という典型例でもある。glibc 2.43リリースと2.44に向けた開発版の間でnewlocaleの呼び出しパスが変わったことが、この地雷を踏む条件になっていた。

対処法

すでにclaudeコマンド自体は動く場合

一番シンプル。

claude update

2.1.245以降に上がれば、mimallocのアロケータシンボルは非公開に戻され（readelf --dyn-symsで確認するとfree/malloc系のシンボルが消えている）、newlocaleとのバッティングも解消される。

claudeコマンド自体が起動できない場合

インストール済みバージョンの一覧を確認し、クラッシュが起きる前のバージョンへ手動でシンボリックリンクを張り直す。

ls -la ~/.local/share/claude/versions/
# 2.1.241 のような、事故前のバージョンが残っていることが多い

# 実行ファイルへのシンボリックリンクを張り替える
which claude
# 例: /home/user/.local/bin/claude がシンボリックリンクだった場合
ln -sf ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude

claude --version
# 2.1.241 (Claude Code) と表示されれば復旧

復旧できたら、そのバージョンのままclaude updateが正常に走るか（＝2.1.245以降を新規取得できるか）を確認してから改めて更新する。古いバージョンにピン留めしたまま使い続けるのは推奨しない。今回のバグはたまたま起動時クラッシュという分かりやすい形で表面化したが、根本原因（NULLチェック漏れのアロケータ）がどこで踏まれるかはビルドやOS更新のタイミング次第で変わりうる。

再発防止として見ておきたいこと

• latestチャンネルを自動更新に任せきりにしない: 今回はlatestが2.1.242→2.1.241へロールバックされたあと、再び壊れた2.1.243へ進む一幕もあった（Issueコメントより）。自動更新後に一度はclaude --versionが通ることを確認する習慣を挟むと、CI/CD環境での気づき遅れを防げる
• glibc 2.44系ディストリビューションを使っている場合は特に: Arch Linux、CachyOS、Manjaro、Fedora Rawhideなどrolling releaseを使っている環境は、今回のように「メジャーどころのディストリでは再現しないバグ」の初弾を踏みやすい。アップデート直後の動作確認は必須にしておきたい

Aug 20, 2026 Claude Codeが「JavaScript heap out of memory」で落ちる原因を、GitHub Issueの実例で整理したClaude Codeが「FATAL ERROR: JavaScript heap out of memory」でクラッシュする原因を解説。.claude.json肥大化・長時間セッション・--resume・MCP重処理の4パターンをGitHub Issue実例つきで整理し、NODE_OPTIONSでの即効対処から恒久対策まで手順化した。読む →

Aug 2, 2026 Claude Codeの終了コード1・3・137：原因を数字だけで決めないClaude Codeの「process exited with code 1/3/127/137」エラーを原因別に整理。認証競合・Windows特有のクラッシュ・OOM・新設定sandbox.network.strictAllowlistまで、切り分け手順つきで解説する。読む →

まとめ

Claude Code v2.1.242/2.1.243でArch Linux・CachyOSなどglibc 2.44環境が起動不能になったバグの正体は、内部メモリアロケータmimallocがプロセス全体のfreeを差し替えたことによるfree(NULL)のNULLチェック漏れだった。glibcが起動時に呼ぶnewlocale()がこの穴を踏み抜き、claude --versionすら通らない全滅状態を引き起こした。

修正は2.1.245で完了済みなので、claude updateが打てる状態ならまずそれを試す。コマンド自体が死んでいる場合は、~/.local/share/claude/versions/に残っている旧バージョンへのシンボリックリンク張り替えで復旧できる。

原因がアプリ側単体でもOS側単体でもなく「両者の噛み合わせ」で発生する典型例でもあるので、Linuxのrolling release環境でClaude Codeを使っている人は、今回のGitHub Issueのスレッドをブックマークしておくと次に似た事象が起きたときの切り分けが早くなるはずだ。