Claude DesktopのCPU使用率が下がらない原因の一つはCoder連携のバグ

Claude DesktopでCPU使用率が高止まりし続ける場合、原因はCoder.comワークスペース検出のバックグラウンドポーリングであることがあります。Coder.comを一度も使っていなくても、メインプロセスが30秒間隔で検出処理を走らせ続け、rendererプロセスとGPUプロセスがCPUを消費し続けます。GitHub issueの報告をもとに、症状の見分け方と、いま取れる対処をまとめます。ここで扱うのはデスクトップアプリ(Windows版)の報告で、ターミナルで使うClaude Code(CLI)のCPU使用率は別の話です。CLI側の修正は後半で触れます。

Claude DesktopのCPUが張り付く症状

Claude Desktop(Windows版)を起動したまま放置すると、rendererプロセスとGPUプロセスの累積CPU使用率が下がりません。タスクマネージャーの詳細タブでは、claude.exeの複数行がCPU時間を積み上げ続けます。ウィンドウを閉じてシステムトレイに収めても、症状は止まりません。

報告されたのは、MSIX(Microsoft Store)パッケージのバージョン1.7196.0.0です。Windows 11 ProとWindows Server 2022の両方で、同じポーリングが観測されています。3件のissueはいずれもWindowsの報告です。

issue #60024の要約には「約1コアを継続して消費」とありますが、同じ報告の数値から計算すると、3時間で1コアの約36%になります。それでも、使っていない機能のために常時CPU時間が積み上がる点は変わりません。

瞬間的なCPU使用率は低く出るため、タスクマネージャーを数秒眺めるだけでは見逃しやすい症状です。報告者は、5秒間のライブサンプルでは瞬間のCPU%が低く出ても、累積では継続的にCPUを消費していると説明しています。詳細タブでCPU時間の列を足し、数分単位で増え方を見ると気づけます。

Claude Desktop自体の基本操作はClaude Desktopとは — インストールから使い方・設定までで扱っています。ここで扱うCPU張り付きは通常機能ではなく不具合(バグ)です。Coder CLIを一度も入れたことがなくても発生します。

原因はCoder.comワークスペース検出の30秒ポーリング

原因は、Claude Desktopに組み込まれているCoder.com連携のワークスペース検出です。連携の設定をしていなくても、メインプロセスが30秒ごとに検出を試み続けます。

Coder CLIがPATH上に見つからない環境では、検出のたびにnew Error()でスタックトレースを生成します。加えて、api.anthropic.com宛てのOAuthトークンキャッシュ参照が1サイクルごとに走ります。main.logには次のログが30秒間隔で記録されます。

[info] [Coder] workspace discovery failed: Error: coder CLI not found on augmented PATH
[info] [oauth] looking up token for orgId=<redacted>, cacheKey=<redacted>...
[info] [oauth] using cached token for orgId=<redacted>
(30秒後に同じパターンが繰り返される)

issue #60024の報告者が提出したmain.logには、このworkspace discovery failedが単一ファイル内に7,966回ありました。約66時間分のポーリングに相当する量です。Coder.comを使う意思のない環境でも、検出処理は止まらないまま積み上がっていました。

別のissue #58732は、同じ根本原因をI/Oの側から報告しています。報告者がSysinternalsのProcess Monitorでclaude.exeの動きを記録したところ、システムのPATHに含まれる全ディレクトリで、30秒ごとにcoder.exe・coder.bat・coder.cmd・coder.ps1の4ファイルを開こうとするCreateFileが並んでいました。gitとghについても、同じ巡回が記録されています。

この走査は、リムーバブルドライブやアーカイブ用のドライブも対象です。ドライブが使えなくなってPATH NOT FOUNDが返る状態になっても、巡回は続きます。報告者は、ドライブがスピンダウンできないことと、ネットワークドライブへの不要な通信が出続けることを副作用として挙げています。

なお「ワークスペース」はClaude Code側にも別の意味で登場する語です。Remote Control起動時に出るWorkspace not trustedエラーはGitリポジトリの信頼ダイアログに関するもので、Coderのワークスペース検出とは別機能です。

「Coder」と「Cowork」も名前が近く、紛らわしい組み合わせです。#60024には、重複の候補としてCowork関連のissue(#56362、#31848)がbotから提示されました。報告者は、どちらもCoworkの話でCoder連携とは別の仕組みだとして、重複とは認めていません。

Coder CLIを追加インストールすると逆に悪化する

「Coderと連携させれば検出が成功して収まるのでは」と考えてCoder CLIを入れるのは逆効果です。#60024の報告者はwinget install Coder.Coder(v2.33.3)で実際に試し、Claude Desktopを完全終了して起動し直したうえで、負荷が悪化することを確かめています。

Coder CLIが導入済みで未認証の状態では、検出のたびに子プロセスのcoder.exeが起動し、coder listを実行します。coder listはnot logged inのエラーで終了し、Claude Desktopは標準エラー出力をラップして、スタックトレース付きのnew Error()を作ります。CLIがない場合のPATH走査に比べ、プロセス起動・標準エラーの読み取り・エラー生成・OAuth参照が毎サイクル積み重なります。

認証済みの行について、報告者は「おそらく軽い成功経路だろう」と書くにとどめています。実際にCoderを使うユーザーの負荷は、この報告からは分かりません。

自分のPCの症状がどちらか切り分ける

CPUが下がらない原因は、Coder検出のほかにもあります。logsフォルダのファイルサイズと、workspace discoveryの行の有無を見ると、報告されている2種類の不具合のどちらに当たるかが分かります。MSIX版のログは次のパスにあります。

$logs = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs"
Get-ChildItem $logs | Sort-Object Length -Descending | Select-Object Name, Length
Select-String -Path "$logs\*.log" -Pattern "workspace discovery" | Select-Object -Last 3

1行目でログフォルダを指定し、2行目でファイルを大きい順に並べ、3行目で該当行の末尾3件を取り出します。#73768の報告者(Desktop 1.18286.0.0)の環境では、main.logの内容が2026年6月4日で止まり、現行の出力はclaude.ai-web.logなどウィンドウ別のファイルに移っていました。そのため、3行目はmain.logだけでなく*.log全体を対象にしています。

有効な対処は今のところトレイからの完全終了のみ

報告時点(1.7196.0.0)では、Coder連携を止める設定がなく、オプトイン化が修正案として挙げられています。ウィンドウを閉じてシステムトレイに収める操作(Xボタン)はポーリングを止めないため、症状は続いたままになります。

#60024の報告者は、修正案を影響の大きい順に7点挙げています。先頭は、Coder連携を利用者の明示的なオプトインにすることです。Coderを使わない大多数の環境で、CPU消費がなくなるためです。2番目は、検出の失敗をセッション中だけ記憶し、起動時に1回判定したら30秒ごとに再テストしないことです。この方式なら、CLIがない場合と未認証の場合の両方が一度に収まります。

3番目以降は、想定内の失敗にnew Error()を使わないこと、接続確認のために毎回子プロセスを起動しないこと、間隔を5分以上に延ばすこと、トレイにいる間は止めること、OAuthトークン参照をこのループから切り離すことです。1サイクルあたりの最大のコストは、スタックトレースの取得だと報告者は見ています。#58732の報告者は、起動時に1回だけ探して結果を記憶し、ドライブが使えなくなったら探索をやめるか間隔を延ばすよう求めています。

似た症状の別の不具合との見分け方

Claude DesktopのCPU高止まりは、Coder連携以外でも起こります。代表例が、main.logのログローテーションが完了せずに空回りし続ける不具合(#73768)です。

#73768の数字は具体的です。メインプロセスのCPUは、アイドル時でも詳細タブで約8〜9%です。タスクマネージャーのプロセスタブでは、プロセスのまとめ表示と正規化の影響で20〜25%に見えます。30秒間のキャプチャで、約70万件のファイルシステムイベントが記録されました。失敗した操作は空きスロットの確認を除いて1件もなく、リネームの要求も1件も出ていません。

もう1つの目印は、ログの重複です。main.logへの出力先が二重に登録されているらしく、同じ行が必ず2回ずつ書かれます。そのため、ファイルが10MiBに達するまでの時間も半分になります。報告者は、10MiBを超えた時点でどのインストールでも起こりうると述べています。

こうした不具合を、まとめて同じ原因と見る向きもあります。#60024の報告者は、過去に報告された「アイドル時にCPUが高い」系のissue(#32020、#19393、#11615)を、同じ根本原因の症状ではないかと見ています。ただし、これは仮説の段階です。

3件はDesktopアプリの挙動の報告で、CLI版には触れていません。CLI側では、Claude Code v2.1.191が、ストリーミング中のCPU使用率を約37%削減しました。macOSでバックグラウンドエージェントの切替が15〜20秒止まる問題と、デーモンのセッショントークンが古くなる問題を直したClaude Code v2.1.203は、CPUとは別の修正です。

3件とも修正されないまま閉じられています

3件のissueに付いたコメントは、重複候補を示すbot、クローズやロックを知らせるbot、報告者本人(#58732には#60024の報告者)のものだけです。#60024と#58732は、クローズ後にロックされています(7月7日と8月19日)。ロックの通知には、クローズ後7日間動きがなかったためと書かれています。

まとめ

報告されたバージョンは、Coder検出が1.7196.0.0、ログローテーションが1.18286.0.0です。自分のバージョンと照らし、ログで症状を確かめてから対処を選ぶ流れになります。