Release verification failedが出るClaude Codeの更新失敗と対処

Release verification failedは「何も入れなかった」という合図

claude update か claude install を実行して、次の一文が出たときの話です。

Release verification failed for Claude Code <version> (<reason>). The update was not installed.

意味は文面のとおりです。これから入れようとしたリリースが本物かどうか確認できなかったので、Claude Codeは何もインストールしませんでした。すでに入っているバージョンは、そのまま使えます。

慌てて消したり入れ直したりする必要はありません。やることは、括弧の中の値を見て次の一手を選ぶだけです。同じメッセージが繰り返されるときの報告の手順は、記事の最後にあります。

括弧内の値ごとの対処

トラブルシューティングのページには、値の見方が2通りだけ載っています。

トラブルシューティングのページは sidecar_fetch_ が何を指す名前なのかを説明していません。名前から原因を推測せず、「この接頭辞なら今すぐ再実行、それ以外なら時間を置く」という分類だけを使うのが安全です。

「すぐ」と「あとで」の使い分けにも、理由は書かれていません。理由は書かれていないので推測になりますが、sidecar_fetch_ 以外の値が出たときに連打しても結果が変わらない可能性はあります。時間を置いて試すほうが、手戻りは少なくなります。

再実行の判定を自動化する例

手作業で毎回メッセージを読むのが面倒なら、出力の接頭辞で分岐するスクリプトを書けます。次は一例です。文言は公式ページの記載に合わせています。実際の出力で文面が変わる可能性があるため、判定はゆるめにしてあります。

out=$(claude update 2>&1); echo "$out"
if echo "$out" | grep -q 'Release verification failed'; then
  if echo "$out" | grep -q '(sidecar_fetch_'; then
    echo "sidecar_fetch_: すぐ再実行"
    claude update
  else
    echo "それ以外の値: 時間を置いて再実行"
  fi
fi

再実行が成功したかどうかは、前の表のとおり Successfully updated from の行で見分けます。2回目も同じメッセージなら、ここで止めて報告に回します。

入っているバージョンは動き続ける

メッセージが出た直後に確かめたいのは、いま使っているバージョンが壊れていないことです。

claude --version
claude doctor

claude --version は 2.1.211 (Claude Code) のようにバージョン番号を出します。claude doctor はセッションを起動せずに、インストールの状態や設定ファイルの検証結果を読み取り専用で表示します。

検証に失敗したのは「新しいバージョンを入れる」処理だけです。いまのバージョンを差し替える前に止まっているので、~/.local/share/claude/versions/ に置かれた実行中のバイナリには手が入りません。作業の途中でこのメッセージが出ても、セッションを閉じる理由にはなりません。ネイティブインストーラーは古いバージョンを自動で削除しますが、起動先が指すバージョンと、同じマシンで実行中のバージョンは残します。

手元のバージョンが minimumVersion を下回っていないかも、あわせて見ておけます。この設定があると、自動更新と claude update は、それより古いバージョンを入れません。

失敗が重なったときの周辺の挙動

バックグラウンドの自動更新が裏で失敗した場合、セッションのフッターには別の赤い一行が出ます。Auto-update failed · Run claude doctor というもので、更新が入らなかったことだけを示し、作業はそのまま続けられます。

claude doctor の Last update attempt: failed (install_failed) には日付が出ますが、原因は出ません。原因を見るには、シェルで claude update を直接実行して、いま紹介しているような個別のエラーメッセージを引き出すのが近道です。

バナーが消えない症状の切り分けはAuto-update failedが消えない原因と対処で扱っています。claude doctor の出力の読み方は/doctorとclaude doctorの違いが詳しいです。

別のエラーと取り違えない

claude update の失敗には、見た目が似た別のメッセージがあります。見分けるポイントは「未検証のリリースを拒否した」のか「ダウンロードが終わらなかった」のかです。

ダウンロードは、接続が切れたときや転送が止まったとき、ファイルのチェックサムが合わないときに、合計3回まで自動で再試行されます。404のようにサーバーが答えを返した失敗は再試行されません。

つまりチェックサム不一致までは再試行の範囲で、それでも通らず「本物と確認できない」と判定されたときに、今回のメッセージに行き着きます。この対応関係までは公式ページが明言していないので、あくまで推測の域を出ません。

社内ネットワークやプロキシ越しの場合

claude update は downloads.claude.ai から取得します。ネットワーク要件のページには、このホストがプラグインの実行ファイルのダウンロード、ネイティブインストーラー、ネイティブの自動更新、更新のバージョン確認に使われると書かれています。

プロキシや社内ファイアウォールを挟むときは、事前に接続だけ確かめておくと切り分けが早くなります。

curl -sI https://downloads.claude.ai/claude-code-releases/latest

最初の行が HTTP/2 200(Windowsの curl.exe では HTTP/1.1 200 OK)なら、サーバーには届いています。403 はプロキシやフィルタの遮断、利用地域の問題が典型です。5xx は一時的なサービス側の問題とされており、数分待って再実行します。

プロキシが必要な環境では、HTTPS_PROXY を設定してから実行します。

export HTTPS_PROXY=http://proxy.example.com:8080
claude update

検証失敗のメッセージそのものが、プロキシに起因すると公式に書かれているわけではありません。ただ、ダウンロード経路を整えておけば、ネットワーク由来の失敗を原因の候補から外せます。

更新を管理者が止めている環境

メッセージが出ない代わりに、そもそも更新が走らない環境もあります。自社配布のためにClaude Code側の更新を止めている場合です。

• DISABLE_AUTOUPDATER=1 はバックグラウンドの確認だけを止めます。手動の claude update と claude install は動きます
• DISABLE_UPDATES=1 は手動の更新を含むすべての経路を止めます。自社の配布経路でバージョンを固定し、利用者に自分で更新させたくない場合の設定です

前者の環境で claude update を実行して検証失敗が出ているなら、後者は関係ありません。後者の環境でメッセージが出るはずがないときは、設定を見直す手がかりになります。どちらも settings.json の env に "1" を入れて設定します。DISABLE_AUTOUPDATER が効いていれば、claude doctor の Auto-updates の行が enabled ではなく disabled (set by env: DISABLE_AUTOUPDATER) と表示されます。

Homebrew・WinGet・Linuxのパッケージマネージャーで入れた環境は、自動更新が既定で動きません。更新はそれぞれの管理コマンドで行うので、claude update の検証失敗を前提にした話はそのままは当てはまりません。ここでの対処は、インストール方法ごとの手順に従います。全体像はClaude Codeのインストール手順にあります。

自分で署名とchecksumを確かめる

「確認できなかった」と言われても、手元で同じ種類の確認はできます。リリースごとに manifest.json が公開されていて、中には各プラットフォームのバイナリのSHA256チェックサムが入っています。このマニフェストにはAnthropicのGPG鍵で署名が付いており、署名を検証すれば、載っているバイナリすべてを間接的に検証したことになります。

手順は4つです。

鍵を取り込んだ直後に WARNING: This key is not certified with a trusted signature! が出ますが、これは新しく入れた鍵では想定内とされています。見るべきは Good signature の行と、手順1の指紋の一致です。

この手動検証には、2つの注意があります。

• マニフェストの署名が付くのは 2.1.89 以降のリリースです。それ以前は、チェックサムだけが載っていて署名はありません
• Linuxのバイナリ自体には、個別のコード署名はありません。直接ダウンロードしたりネイティブインストーラーで入れたりした場合は、マニフェスト署名で確かめます。apt・dnf・apkなら、パッケージマネージャーがリポジトリの署名鍵で自動検証します

claude update が内部でどんな検証をしているかは、セットアップのページにもトラブルシューティングのページにも載っていません。手動検証の結果と、メッセージが出る理由を同一視しないでください。手動で Good signature が出ても、そのことが claude update の再実行結果を保証するわけではありません。

macOSは「Anthropic PBC」の署名とAppleの公証、Windowsは「Anthropic, PBC」の署名がバイナリに付いています。確かめるコマンドは、macOSが codesign --verify --verbose ./claude、Windowsが Get-AuthenticodeSignature .\claude.exe です。

再実行しても直らないときの報告

同じメッセージが繰り返されるときは、GitHubのissueを立てるのが公式の案内です。次の3点を添えます。

1. 使っているOS
2. 実行したインストールのコマンド
3. エラー出力の全文(括弧内の値を含めます)

セッションを開ける状態なら、Claude Code内の /feedback からも報告できます。claude --version が通るのに別の症状があるときは、claude doctor の診断も取っておきます。

括弧の中の値は、公式の分類でも原因の切り分けでも唯一の手がかりです。伏せずにそのまま貼るのが、返事を早くするコツです。