Installation was killed before it could finish (exit code 137)

インストール処理が、完了する前に外部から強制終了されました。

⭐ 終了コード 137 には明確な意味があります。 137 = 128 + 9 で、シグナル 9（SIGKILL）で殺されたことを示します。SIGKILL はプロセス側で捕まえられないため、後始末をする間もなく落ちます。

誰が殺したのか、で原因が決まります。

⚠️ Docker や CI で起きた場合は、ほぼメモリ不足です。 ローカルの物理マシンで起きた場合は、空きメモリかディスクを疑ってください。

1. まず再実行する

一時的なリソース不足なら、これで通ります。

claude update

毎回同じところで落ちるなら、恒常的な制限に当たっています。 以下へ進んでください。

2. メモリの空きを確認する

macOS / Linux

free -h 2>/dev/null || vm_stat

Windows（PowerShell）

Get-CimInstance Win32_OperatingSystem |
  Select-Object @{n='空きMB';e={[math]::Round($_.FreePhysicalMemory/1KB)}},
                @{n='合計MB';e={[math]::Round($_.TotalVisibleMemorySize/1KB)}}

Docker コンテナ内

cat /sys/fs/cgroup/memory.max 2>/dev/null || cat /sys/fs/cgroup/memory/memory.limit_in_bytes

⚠️ cgroup のバージョンでパスが違います。 現行の Docker はほぼ v2 で、memory.max を見ます。上のコマンドは v2 を先に試し、無ければ v1 のパスに落ちるようにしてあります。

実測した出力は次のとおりです。

max と出たならコンテナ側の上限は原因ではありません。ホストの空きメモリを疑ってください。

3. OOM Killer に殺されたか確認する

Linux

dmesg -T | grep -i -E 'killed process|out of memory' | tail -5

Docker（コンテナが終了している場合）

docker inspect CONTAINER --format '{{.State.OOMKilled}} {{.State.ExitCode}}'

CONTAINER はコンテナ名か ID に置き換えてください。

⭐ true 137 と出れば、メモリ不足で確定です。 実際に上限32MBのコンテナで意図的にメモリを使い切らせたところ、次の出力になりました。

true 137

⚠️ --rm を付けて起動していると、終了と同時にコンテナが消えて inspect できません。 原因を調べるときは --rm を外してください。

⚠️ 終了コードはパイプすると見えなくなる

# ❌ 見えるのは tail の終了コード（0）
docker run ... | tail -1
echo $?        # → 0

# ✅ パイプしない
docker run ...
echo $?        # → 137

これは Docker に限りません。 CI のログで「エラーが出ているのにジョブは成功している」場合、パイプの先の終了コードを見ていることがあります。set -o pipefail を使うか、パイプを外して確認してください。

4. コンテナのメモリ上限を上げる

docker run

docker run --memory=4g --memory-swap=4g your-image

docker compose

services:
  app:
    deploy:
      resources:
        limits:
          memory: 4G

Docker Desktop（Windows / macOS）

まず、Docker 全体にいくら割り当てられているかを確認します。推測しないでください。

docker info --format 'Total Memory: {{.MemTotal}}'

⚠️ 「Docker Desktop の既定値は小さい」というのは、現在は必ずしも正しくありません。 WSL2 バックエンドではホストメモリの約半分が既定で割り当てられます（実測した環境では 15.57GiB）。

小さい値になるのは、次の場合です。

docker info の値が十分大きいなら、原因は Docker の割当ではありません。コンテナ個別の --memory 指定か、ホストの空きメモリを疑ってください。

WSL2 バックエンドを使っている場合は、%USERPROFILE%\.wslconfig で上限を設定します。

[wsl2]
memory=8GB

編集後は WSL を再起動してください。

wsl --shutdown

5. ディスクの空きを確認する

メモリではなくディスクが原因のこともあります。

macOS / Linux

df -h ~

Windows（PowerShell）

Get-PSDrive -PSProvider FileSystem |
  Select-Object Name, @{n='空きGB';e={[math]::Round($_.Free/1GB,1)}}, @{n='使用GB';e={[math]::Round($_.Used/1GB,1)}}

一時ファイルの置き場所が別ドライブになっていることがあります。あわせて確認してください。

6. 他のプロセスを止める

物理マシンで起きている場合、インストール中だけでも重いプロセスを終了させます。

Windows（メモリ使用量の上位）

Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 8 Name, @{n='MB';e={[math]::Round($_.WorkingSet64/1MB)}}

macOS / Linux

ps aux --sort=-%mem | head -8

7. CI で起きている場合

• ジョブのメモリ上限を上げる（サービスによって設定箇所が異なります）
• 同一ジョブで並列に走らせている処理を減らす
• インストールを別ステップに分離し、重い処理と同時に走らせない

• ⭐ 終了コードは原因を示す情報です。 137 を見たら真っ先にメモリを疑う、と覚えておくと切り分けが一瞬で済みます（134=SIGABRT、143=SIGTERM）
• Docker の割当は docker info で実際の値を見る。 「既定値が小さいはず」という思い込みで設定をいじると遠回りになります
• ⚠️ 終了コードを見るときはパイプしない。 | tail すると 137 が見えず、原因の特定が丸ごと遅れます
• CI では、インストールをキャッシュして毎回実行しないようにすると、リソース競合そのものが減ります
• 物理マシンで頻発するなら、それは Claude Code 固有の問題ではなく環境全体が逼迫しているサインです。他の作業にも影響が出ています