Claude Code がプロセスの code 1 終了を表示したとき、最初にやるべきことは再インストールではありません。この文は、Claude Code が起動したプロセスが汎用の失敗コードで終了したことを示すだけです。原因がログイン、Terms 同意、IDE の子プロセス、PATH、wrapper、hook、古いセッション、バージョン更新、サービス状態のどれかはまだ分かっていません。
まず分岐ボードで入口を決める
日本語の公開事例では、ブラウザで利用規約に同意し直す話、設定ファイル、GitHub issue、VS Code や Cowork の話が並びます。どれも一部のユーザーには正しい可能性がありますが、全員に同じ修正を当てるのは危険です。最初に必要なのは、失敗した起動面を固定することです。
| 見えている状態 | 最初の分岐 | 安全な初手 | 同じ経路での確認 | エスカレーション条件 |
|---|---|---|---|---|
| 通常ターミナルで失敗する | ターミナルまたはインストール | 新しい shell で同じディレクトリに入り claude doctor | 同じコマンドを再実行 | 新 shell でも同じ失敗 |
| VS Code、Cursor、JetBrains だけで失敗 | IDE サブプロセス | システム端末で同じコマンドを実行 | IDE と端末の差分を見る | 端末は成功、IDE は失敗 |
| ログイン、アカウント変更、Terms 後に失敗 | 認証またはセッション | /status を確認し、対象経路だけ再認証 | 同じ login path を再実行 | status 正常でも同じ経路が失敗 |
| Windows や shell が binary、Git、PATH を見つけない | PATH とインストール | where claude、Git、PATH を確認 | 新しい端末で binary を確認 | 前提条件は通るが起動は失敗 |
| npm、hook、alias、CI 経由で失敗 | wrapper または script | wrapper を外して直接 claude | 1層ずつ戻す | direct path は成功、wrapper で再発 |
| ある古い会話や workspace だけ失敗 | セッション状態 | 新しい最小セッションを作る | 最小タスクを実行 | 新セッションでも失敗 |
| 更新直後や障害中に大量発生 | バージョンまたは状態 | version と status 確認時刻を記録 | 状態や version 変化後に同路確認 | 証拠パケットが揃う |
この表は修正リストではなく、破壊的な操作を遅らせるためのものです。再インストール、全キャッシュ削除、全 token ローテーション、設定ディレクトリ削除を同時にやると、後で原因が分からなくなります。修正完了の判定は、別の経路が動くことではなく、元の失敗経路が最小変更後に動くことです。
このエラーが意味する範囲
この code 1 表示は、プロセスが一般的な失敗コードで終了したという意味です。API リクエストまで到達していない場合もありますし、IDE が起動した subprocess、hook、設定読み込み、auth refresh、サービス劣化、古い session の中で起きている場合もあります。
したがって、単純な「再ログインで直る」「再インストールで直る」という答えは強すぎます。ブラウザで Terms に同意し直すことで直るケースはありますが、それは認証・利用条件分岐です。VS Code の debugger auto-attach が影響するケースもありますが、それは IDE 分岐です。hook の exit code と Claude Code 本体の起動失敗は別物です。
作業ルールは固定してください。1つだけ変える。同じ起動経路を保つ。変更後に同じ経路で確認する。同じ経路がまだ失敗するなら、次の分岐に行く前に証拠を残す。この順番なら、直ったときに理由も残ります。
ステータス、認証、Terms、ログイン
日本語の事例では、ブラウザ側の規約同意やログイン状態を原因として扱う報告が目立ちます。この分岐は重要ですが、全体の答えにしてはいけません。ログイン、SSO、アカウント切り替え、subscription/API key の切り替え、OAuth、Terms 更新、またはサービス劣化の直後に始まった場合に、この分岐から始めます。
まず Anthropic の status を確認し、確認時刻を残します。Claude Code が slash command を受け付けるなら /status で現在の経路とアカウントを見ます。ブラウザで Terms 同意が必要そうなら、その同意を済ませて同じ経路を再実行します。認証 path が怪しい場合は対象 path だけ logout/login し、全 token や全 config を同時に消さないでください。
ログに HTTP 500、request id、server error が出てきたら、Claude Code API Error 500 ガイド に移動します。subscription と API key の経路が混ざっているなら Claude Code API key と subscription billing ガイド が適切です。使用量制限が見えているなら rate limit の問題として扱います。
Windows、PATH、インストール
PATH/インストール分岐は、command not found、wrong binary、Git 不足、shell 不一致、permission error、初回セットアップ失敗が見えているときだけ第一候補にします。code 1 だけでインストール破損を決めつけると、動いている binary を無駄に変えることになります。
macOS/Linux では claude --version、which claude、claude doctor を確認します。Windows では where claude、git --version、PowerShell/WSL、PATH の順序を確認します。新しい端末で version が出ないならインストール分岐です。version が出るのに特定の IDE や project だけで落ちるなら、インストールよりも IDE、環境、session、wrapper を疑います。
まだ前提条件が整っていない場合は Claude Code インストールガイド が近い記事です。ここでは、インストール済みの Claude Code が特定の起動経路で code 1 を返す場面を扱います。
IDE、環境変数、セッション
IDE 分岐は短く見えて、実は情報量が多い分岐です。VS Code、Cursor、JetBrains は、system terminal と異なる working directory、integrated terminal shell、extension setting、debugger setting、environment variables で subprocess を起動できます。公開 issue では、auto-attach や debugger 環境が process 起動に干渉する例もありました。全員に当てはまるわけではありませんが、比較する価値はあります。
まず system terminal で同じ directory に入り、pwd、claude --version、最小の claude 起動を行います。次に IDE 内で同じ directory と同じ command を使います。system terminal は成功し IDE だけ失敗するなら、extension output、workspace settings、launch/task config、integrated terminal shell、auto-attach、injected env、working directory を確認します。
両方で失敗する場合は、環境変数と session に移ります。PATH、proxy、token/auth、shell startup、Node shim、会社ネットワークなど、起動に影響しうるものだけを見ます。secrets を表示したり、全部削除したりしないでください。session については、新しい一時ディレクトリまたは最小セッションで同じ種類の小さなタスクを試します。新セッションが動くなら旧状態が原因の一部です。
Hooks、wrapper、npm script、CI
外側の script が code 1 を返しているのに、ユーザーには Claude Code の process exit と見えることがあります。npm script、alias、shell function、pre-commit hook、CI、task runner、timeout wrapper はこの分岐です。
直接 claude を実行して成功するか確認します。成功するなら、alias、npm script、hook、CI step、timeout wrapper を1層ずつ戻します。最初に error を戻した層が第一修復対象です。その層の exit code、permission、working directory、environment、timeout、stderr 処理を見ます。
direct path が成功しているのに Claude Code を再インストールしても、原因層には触れていません。CI では secret の有無、非対話 shell、workspace 権限、timeout、ログの省略がよく原因になります。wrapper の問題を Claude Code 本体の問題にしないことが重要です。
更新回帰またはリアルタイム障害
更新直後に始まった場合や、同時期に GitHub issue、Reddit、SNS で同じ報告が増えている場合、version/status 分岐を保持します。ただしこれは現在の証拠でなければなりません。
claude --version、インストール経路、OS、shell、IDE extension version、system terminal の結果、status 確認時刻、直前の設定変更を記録します。状態が戻った後に同じ経路が復旧したなら service branch です。特定 version のみ再現し、修正 version で消えるなら version branch です。どちらでもないなら、更新だけを原因にし続けないでください。
この分岐の目的は、待つべきときにローカル状態を壊さないことです。障害中に cache、token、PATH、extension を全部変えると、復旧後も原因が見えません。version regression を報告するなら、version と failing surface が必要です。
同じ経路での検証と証拠パケット
修正完了は、元の failing path で判断します。VS Code で落ちていたなら、system terminal 成功は分類材料です。npm script で落ちていたなら、direct command 成功は wrapper 分岐の証拠です。どちらも元の経路の修復完了ではありません。
エスカレーション前に集めるものは、起動経路または完全な command、完全な error text、Claude Code version、OS、shell、IDE、status 確認時刻、認証経路、直前の変更、system terminal と IDE/wrapper の比較、最小再現手順、logs、session id、request id または correlation id です。request id が無いなら、それも情報です。API に到達していない local launcher failure かもしれません。
良い報告は短くても分岐を持っています。「macOS、zsh、version X、system terminal は成功、VS Code 内だけ失敗、auto-attach を無効化すると同じ IDE path が復旧」のような形です。「code 1 が出る」だけでは、相手は同じ分岐表を最初からやり直す必要があります。
分岐別の最小修正
| 分岐 | 先にやること | 先に避けること | 成功の証拠 |
|---|---|---|---|
| ターミナル | 新 shell、同じ directory、claude doctor | 全 config 削除 | 同じ command が起動 |
| 認証/セッション | /status、対象 path の再認証 | 全 token 変更 | 同じ login path が成功 |
| Windows/PATH | where claude、Git、PATH | 証拠なしの reinstall | 新端末で binary が見える |
| IDE | system terminal 比較 | Claude Code 全体を疑う | IDE path が復旧 |
| 環境変数 | PATH/proxy/token/shell startup | secrets 表示や削除 | 1つの差分で説明できる |
| wrapper | direct path を確認し層を戻す | 先に Claude Code を変更 | wrapper 層が孤立する |
| 状態/バージョン | status 時刻と version を記録 | 古い投稿を現在証拠にする | 状態や version 変化後に同路復旧 |
| 不明 | 証拠パケットを作る | ランダム修正 | issue に分岐メモがある |
よくある質問
これは Claude Code が落ちているという意味ですか？
それだけでは分かりません。status は必ず確認しますが、terminal、IDE、auth、wrapper、session、PATH も同じ可視メッセージを出せます。
最初に再インストールすべきですか？
多くの場合は違います。binary が無い、PATH が壊れている、Git や shell 前提条件が満たされない、permission が怪しい、といった install branch の証拠があるときだけ初手になります。
最速で安全な確認は何ですか？
起動面を特定し、system terminal と失敗経路を比較することです。その後、1項目だけ変えて同じ経路で確認します。
VS Code や Cursor だけで失敗する場合は？
system terminal で同じ directory と同じ command を試します。terminal が成功するなら extension logs、workspace settings、integrated terminal shell、auto-attach、environment variables、working directory を確認します。
API 500 や rate limit と同じですか？
違います。process exit は API request 前に起きる可能性があります。HTTP 500 や request id が見えるなら API Error 500 ガイド に移動してください。使用量制限が見えるなら Claude Code rate limit ガイド が適切です。
作業ルール
Claude Code の code 1 は、単一の魔法の修正ではなく分岐ルーティングの問題として扱います。起動面を決め、破壊性の小さい確認から始め、1つだけ変え、同じ経路で再確認し、それでも失敗する場合だけ証拠付きでエスカレーションします。