Claude CodeがWindows Serverで固まる — 2022での起動時ハングの切り分け
Windows Server 2022で出力なしにCPUを1コア使い続ける症状を、issue #100969の報告と公式docsからまとめます。--versionは通る点、確認済みの除外項目、手元での切り分け手順を載せます。
Windows Server 2022でclaude.exeを起動すると、画面に何も出ないまま、プロセスがCPUを1コア分使い続けて返ってこない。claude --versionはすぐ答えるのに、claude -p "hello"は何分待っても終わらない。GitHubのissue #100969は、この症状をClaude Code 2.1.295で報告しています。
issueには原因が書かれておらず、修正版も示されていません。この記事では、報告された条件と除外済みの項目、そして自分のサーバーで同じ症状かどうかを見分ける手順をまとめます。
報告されている症状と環境
issueの本文から、症状と環境を表にします。
| 項目 | 報告の内容 |
|---|---|
| OS | 報告の内容Windows Server 2022(21H2、ビルド20348.5622) |
| 構成 | 報告の内容複数ユーザーがRDPで入るターミナルサーバー(報告時は2ユーザーがログイン中) |
| バージョン | 報告の内容Claude Code 2.1.295 |
| 症状 | 報告の内容出力が一切なく、無期限に固まる。--debugを付けても同じ |
| プロセス | 報告の内容claude.exe1つにつきCPU約1コア、メモリ約19MB。7つ同時に溜まった例あり |
| 動くもの | 報告の内容claude.exe --versionは即時に返る |
| 回帰 | 報告の内容以前のバージョンでは動いていたと報告(最後に動いた版は未記入) |
メモリが約19MBと小さいまま、CPUだけが1コア分張り付く点が特徴です。報告者は「busy loop(空回り)に見える」と書いています。ただし、これは報告者の見立てで、原因の裏付けではありません。
issueにはbug・regression・platform:windows・has reproのほかduplicateのラベルも付いています。コメントは0件で、状態はopenです。
Windows Server 2022は対応環境に入っているか
公式のシステム要件では、Windowsは「Windows 10 1809以降、またはWindows Server 2019以降」とされています。2022は範囲に入るので、非対応環境の問題として片づけることはできません。要件の全体はClaude Codeのシステム要件に、導入手順はWindowsへのインストールにまとめています。
「設定のせい」ではないと確認された範囲
報告者は、次の項目を原因から外しています。
- プロジェクト設定: 空のフォルダで実行しても再現する
- ユーザー設定と状態:
CLAUDE_CONFIG_DIRを空のフォルダに向けても再現する - ネットワーク: リクエストを送る前の段階で固まっている
- ウイルス対策・VPN・プロキシ: いずれも使っていない
- MCPサーバーとhooks: どちらも使っていない
報告者が外した項目は、debug-your-configの「Test against a clean configuration」の手順と重なります。クリーンな設定ディレクトリでも再現するなら、原因はユーザー設定とプロジェクト設定の外にあります。設定を疑って.claudeを消して回る前に、この除外ができているかを確認すると遠回りを避けられます。
同じ症状かを見分ける手順
自分のサーバーで同じ症状かどうかは、次の順で確かめられます。cmdで実行します。
起動時のハングを確かめる順番
- 1
--versionが通るか見る
claude --versionが即座に返れば、実行ファイルの配置とPATHは正常です。ここで失敗するなら別の問題です。 - 2
クリーンな設定ディレクトリで実行する
CLAUDE_CONFIG_DIRを新しい空フォルダに向け、空のフォルダから短いプロンプトを実行します。 - 3
CPUとメモリを観察する
別ウィンドウで
claudeのプロセスを見て、CPUが張り付いたままメモリが増えないかを確かめます。 - 4
デバッグログをファイルに残す
出力が空でも、
--debug-fileならログがファイルに残る可能性があります。
issueの再現手順は次のとおりです。
claude.exe --version
set CLAUDE_CONFIG_DIR=C:\temp\cc-clean
mkdir C:\temp\cc-clean
cd C:\temp\cc-clean
claude.exe -p "hello"最後の行で何も返らず固まれば、報告と同じ状態です。プロセスの状況は、別のPowerShellで確かめます。
Get-Process claude | Select-Object Id, CPU, WorkingSet64CPUの値は累計の秒数です。数秒おきに2回実行して、数字が増え続けていれば計算を続けています。止まっていれば、CPUを使わず待っている状態で、別の症状です。
デバッグログは、ファイルに書き出す形で取ります。
claude.exe -p "hello" --debug-file C:\temp\claude-debug.log--debug-fileは書き出し先を指定でき、指定するとデバッグモードが有効になります。報告者のissueでは--debugでも画面に何も出ていないため、ログがどこまで進むかは自分の環境で試すしかありません。ログの場所と使い分けは--debugと/debugの使い方で整理しています。
設定を疑う場合の切り分け
クリーンな設定でも固まるなら、設定側の切り分けは済んでいます。逆に、クリーン設定では動くのに通常の環境で固まるなら、設定が原因の可能性が残ります。その場合は、全カスタマイズを無効にする--safe-modeが最初の一手です。
claude --safe-mode--safe-modeはCLAUDE.md・スキル・プラグイン・hooks・MCPサーバーなどを読み込まずに起動し、認証・モデル選択・組み込みツール・権限は通常どおり動きます。問題が消えればカスタマイズのどれかが原因で、消えなければ設定の外です。詳しい使い方はsafe modeでの切り分けにあります。
Claude Desktopから使っている場合
issueの報告者は、Claude Desktopのセッションでも同じ症状に遭っています。Desktopのログには、最初の応答が来ないまま約991秒で無活動のタイムアウトになり、CLIが初期化の前に終了した、という趣旨の記録が出ています。
つまりDesktopから見ると、裏で動かすCLIが応答しないために、セッションが何も返さない形になります。
固まったプロセスは自動では片づかず、溜まっていきます。報告では7つ同時に溜まっていました。Windowsでの溜まったclaude.exeの掃除はclaude.exeが溜まる原因と手順を参照してください。
マルチユーザーのサーバーでは、溜まったプロセスが1コアずつ使うため、他のユーザーの作業にも響きます。固まったと気づいた時点でプロセスを止めるのが先決です。
Get-Process claude -IncludeUserName | Where-Object UserName -eq "$env:USERDOMAIN\$env:USERNAME" | Stop-Process他のユーザーのセッションで動いている正常なclaudeまで止めないよう、自分のユーザーのプロセスだけに絞っています。-IncludeUserNameの使用には管理者権限が必要です。
Desktopのログの読み方
issueに貼られたClaude Desktopのログは、4行とも「CLIが最初の応答を返さなかった」ことを別の角度から記録しています。
| ログの文言(要旨) | 読み取れること |
|---|---|
timed out after 991s of inactivity (hadFirstResponse=false, seconds_since_stderr=never) | 読み取れること約991秒、最初の応答もstderrへの出力もなかった |
probe_result=no_answer | 読み取れること状態確認(probe)の結果が「応答なし」だった |
query.interrupt() did not resolve within 1500ms | 読み取れること中断の要求も、最初のバイトが出る前には受け付けられなかった |
Temporary query did not answer within 90000ms | 読み取れることコマンド一覧の取得用の一時的な問い合わせも、90秒で答えなかった |
seconds_since_stderr=neverは、プロセスが一度もエラー出力すら出していないことを示します。クラッシュではなく、応答しないまま生きている状態です。ターミナルでも画面が真っ白のまま返らない症状と、同じ現象の別の見え方です。
Desktop側で待つだけではCLIが動き出さないので、まずCLI単体で-pが返るかを見るのが出発点です。
公式docsにある「固まる」系の記載との違い
公式のトラブルシューティングには「起動後に固まる」系の記載がいくつかありますが、今回の症状とは条件が違います。
| 公式の記載 | 条件 | 今回の症状との違い |
|---|---|---|
claude updateとclaude doctorが固まる | 条件シェル設定ファイルのパスがディレクトリになっている。v2.1.214で修正済み | 今回の症状との違い報告はv2.1.295で、-pの実行で固まる |
| 高いCPU・メモリ使用 | 条件大きなコードベースやコンテキストの肥大 | 今回の症状との違い空フォルダでも再現し、メモリは約19MBのまま |
| コマンドが固まる・応答しない | 条件Ctrl+Cで中断して再開する | 今回の症状との違い起動の段階で止まり、再開する会話がない |
claude updateとclaude doctorのハングは、シェル設定ファイルの位置にディレクトリがあると起きる別の不具合です。今回の報告者は--versionが通り、-pで固まるので、この条件には当たりません。
報告するときに添える情報
issueの報告者は、Process Monitorのトレースなど追加の診断に協力すると書いています。同じ症状に当たったら、次の情報があると原因の絞り込みに役立ちます。
winverで確認したビルド番号(報告では20348.5622)claude --versionの出力- ターミナルサーバーかどうか、同時ログインのユーザー数
- クリーンな
CLAUDE_CONFIG_DIRで再現するか --debug-fileで残ったログの有無(中身に機密が入っていないか確認してから共有する)- 以前に動いていたバージョン(報告では未記入)
同じサーバーの別ユーザー、または別のマシンのWindowsで同じ版が動くかも比べておくと、サーバー固有の問題かどうかが分かります。報告では、2人のユーザーがログインしたRDP環境という条件が付いていて、単一ユーザーの環境で再現するかは書かれていません。
特に「最後に動いたバージョン」は、回帰の範囲を絞る決め手になります。以前のバージョンを入れ直して試せる環境なら、動いたバージョンと固まったバージョンを控えておくと、報告の価値が上がります。
切り分けの結果ごとの次の一手
--versionも通らない: PATHまたはインストールの問題です。Windowsへのインストールの確認に戻ります。- クリーン設定では動く: 設定が原因です。
--safe-modeから始めて、カスタマイズを1つずつ戻します。 - クリーン設定でも固まり、CPUが張り付く: issue #100969と同じ型です。ビルド番号とバージョンを添えて、同issueに状況を足すのが近道です。
- 固まるがCPUは使っていない: 別の原因です。ネットワークや認証の待ちを疑い、
--debug-fileのログを読みます。
まとめ
Windows Server 2022での起動時ハングは、設定やネットワークの外にある問題として報告されている段階です。原因も修正版も示されていないため、手元でできるのは、同じ症状かの確認、固まったプロセスの停止、再現情報の整理までです。--versionが通る点と、クリーンな設定でも再現する点が、この症状を見分ける二つの目印になります。