Claude Media
Windowsでclaude.exeが溜まる原因と、メモリを空ける掃除の手順
Claude CodeTips

Windowsでclaude.exeが溜まる原因と、メモリを空ける掃除の手順

Windowsのデスクトップアプリで終わったセッションのclaude.exeが残り続け、1日でメモリを数GB使う問題。見分け方、溜まる仕組み、アーカイブと再起動での掃除をまとめます。

読了目安 約12分

Windowsのデスクトップアプリで半日ほどClaude Codeのタブを開いては閉じていると、タスクマネージャーに claude.exe が数十個並び、メモリが数GB埋まることがあります。タブ上では終わっているセッションでも、裏のプロセスは生きたままです。

GitHubのissue #96299がこの症状の報告で、openのままです。ある報告では11時間の利用で claude.exe が42個、合計約3.4GBでした。以下では、見分け方、溜まる仕組み、掃除の手順、掃除の前に知っておきたい注意点の順にまとめます。

溜まったclaude.exeの見分け方

タスクマネージャーでは、名前が Claude の行をまとめて展開すると claude.exe が並びます。ただし1つのウィンドウでも、Electronの補助プロセス(GPU、レンダラー、ユーティリティ、クラッシュハンドラー)が十数個は動いています。issueの報告者は、再起動直後の正常な状態を約13個としています。

溜まっているのは、そのほかの「セッションプロセス」です。見分けるカギはコマンドラインで、セッション側には --output-format stream-json が付いています。補助プロセスの側には --type= が付いています。

Get-CimInstance Win32_Process -Filter "Name='claude.exe'" |
  Where-Object { $_.CommandLine -like '*--output-format stream-json*' } |
  Sort-Object CreationDate |
  Select-Object ProcessId, ParentProcessId, CreationDate

出力の行数がセッションプロセスの数です。親プロセスはどれも同じメインのGUIプロセスで、作成日時はアプリの起動時刻から今までばらけて並びます。issueでは、27個の追加プロセスがまさにこの形でした。

使用メモリは「プライベート」で測る

Get-Process や WorkingSetSize の値は共有ページをプロセスごとに数えるため、100個近く並ぶと合計が膨らみます。issueのコメントでは、通常のワーキングセットで32.33GBと出した合計が、プライベートワーキングセットで測り直すと同じ程度の晩に約3分の1になったと訂正されています。タスクマネージャーの「メモリ」列と同じ値を取るには、次のカウンターを使います。

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process `
  -Filter "Name LIKE 'claude%'" |
  Select-Object IDProcess, @{n='PrivateMB';e={[int]($_.WorkingSetPrivate/1MB)}}

コメントの実測では、セッションプロセス1個あたりの中央値が212MB(範囲185〜287MB)で、外れ値はありませんでした。別の報告者は、アイドルのセッションが400〜470MBのプライベートコミットで横ばいに推移し、増え続けるリークではないと分析しています。測り方で値は変わりますが、1個ごとの重さより、個数が増えることのほうが効きます。

なぜ溜まるのか

issueとコメントを突き合わせると、仕組みは次のとおりです。

  • セッションを触るたびに、そのセッション用のCLIプロセスが1つ起動する
  • セッションが終わって isRunning: false になっても、プロセスは残る
  • 消えるのは、セッションをアーカイブしたときか、アプリを終了したとき
  • 前回のウィンドウを復元すると、使わないセッションでも --resume 付きで起動する

つまり、アプリを開きっぱなしにしている時間と、触ったセッションの数に比例して増えます。報告では、48セッションのうち実際に動いていたのは2つだけで、残りの約46個は終わったセッションでした。

周りにも付いてくる

セッションプロセスの下には、別のものがぶら下がります。

  • MCPサーバー: 7セッションで約170プロセス、合計5.8GBという報告がある
  • ターミナルペイン用の powershell.exe: ペインを開いたセッションごとに1つ。1つ約63MBで、14個が残った報告がある
  • %LOCALAPPDATA%\Temp\claude\<session-id>\: セッションごとの作業ディレクトリで、約3GBに達した報告がある
  • git fsmonitor--daemon: グローバルで core.fsmonitor=true にしていると、複数のリポジトリやworktreeを触るたびに常駐プロセスが増える。116個で約1.6GBの報告がある

PowerShellのほうは、アプリを閉じた後も残る例が別のコメントにあります。Windows PowerShell 5.1で動いたシェルが1つ13〜17GBまで膨らんだという報告です。ここまで重くなる経路は、このissueでは1件だけです。

掃除の手順

重い順ではなく、アプリへの影響が小さい順に並べます。

1. 終わったセッションをアーカイブする

サイドバーでセッションにカーソルを合わせ、アーカイブのアイコンを押します。Claude Codeの公式ドキュメントによれば、PRがマージまたはクローズされたセッションを自動でアーカイブする設定が、Settings > Claude CodeのAuto-archive after PR merge or closeです。対象は、実行が終わったローカルセッションだけです。

ただし、アーカイブでプロセスが消えるかは報告が割れています。

報告アーカイブ後の挙動
あるコメント(バンドルCLI 2.1.281)アーカイブ後の挙動終わった4セッションをアーカイブして、約5GBのコミットが戻った
別のコメント(バンドルCLI 2.1.280)アーカイブ後の挙動終わったセッションをアーカイブしても何も解放されなかった。同じ日に開いたセッションのプロセスは、アプリ再起動まで残った

版やビルドによる差の可能性があります。まず1つアーカイブして、先ほどのコマンドで個数が減るかを見てから、残りを片づけると確実です。設定画面のArchive inactive sessionsも使えますが、コメントによれば粒度が日単位で、1日の中で溜まる速さには追いつきません。実行中やバックグラウンドのセッションは対象外とも書かれています。

2. アプリを終了して起動し直す

issueの報告者が見つけた回避策は、claude.exe を全部終了してアプリを起動し直すことです。再起動直後は、約13個(ほぼElectronの補助プロセス)まで戻りました。余分なセッションプロセスは、通常の動作に必要ないということです。

公式ドキュメントの「App won't quit」の項は、Windowsではタスクマネージャー(Ctrl+Shift+Esc)から Claude を終了するよう案内しています。

実行中のタスクがあるときは、終わるのを待ってから落とします。強制終了すれば、その実行は途中で切れます。

3. セッションを1つずつ、きれいに降ろしたいとき

プラグイン「RAM Sleeper」の作者によれば、Stop-Process で落とすとアプリ側に「Claude Codeがクラッシュした」と出ます。そこでコンソールにCtrl+Cを送ってCLIを正常終了させる方式にしたと述べています。会話の記録は残り、次のメッセージを送ると同じ会話で再開します。

RAM Sleeperは、セッション名とメモリを並べて表示し、アイドルのセッションを自分で選んで降ろす作りです。自動で降ろす機能はなく、実行中のセッションを降ろすには追加のフラグが要ります。第三者のコードをそのまま走らせることになるので、導入するかはリポジトリを読んでから決めてください。

4. アプリを閉じた後に残ったシェルを消す

アプリを閉じても残る powershell.exe は、コマンドラインに CLAUDE_CODE_SHELL_LAUNCHER_SCRIPT が入っています。コメントで紹介された回避策は、1GB超のPowerShellを一括で止める方法でしたが、自分で開いている別のPowerShellも巻き込みます。起動スクリプトの名前で絞るほうが安全です。

Get-CimInstance Win32_Process -Filter "Name='powershell.exe'" |
  Where-Object { $_.CommandLine -like '*CLAUDE_CODE_SHELL_LAUNCHER_SCRIPT*' } |
  ForEach-Object { Stop-Process -Id $_.ProcessId }

この絞り込みは、コメントで使われた識別文字列を使った書き方です。アプリが起動中に実行すると、使用中のシェルも落とします。アプリを閉じてから実行してください。

スケジュールタスクで増えるのか

アプリのスケジュールタスクを多用する環境では、実行のたびにセッションが生まれます。あるコメントは、49個のルーチンのうち39個が24時間以内に動くノードで、79個のセッションプロセスが並んだと報告しました。

ところが数日後のコメントで、同じ報告者が見立てを取り下げています。測り直した晩に残っていたのは、人が開いて放置した39個のタブで、スケジュール実行のセッションは1つだけでした。CLI 2.1.286では、終わったルーチンのプロセスは終了していたということです。アプリの再起動を挟んでいるため、何が変わったかは報告者自身も特定できていません。

スケジュールの設定自体はClaude Code Desktopの定期実行タスクの記事にまとめてあります。

Linuxの共有サーバーでも同じ形

Windows以外でも、同じ挙動の報告がissueにあります。LinuxでデスクトップアプリをSSH経由の共有サーバーにつないだ環境で、開発者1人が1日で41個のセッションプロセス(約10GB)を溜めた計測です。最長のプロセスは、会話の動きがないまま28日間生きていたとのことです。

この報告者の運用は、会話ログの最後の "timestamp" が30分以上前のセッションを、子プロセスごと終了させるcronでした。ファイルの更新時刻はタイトルの更新などでも変わるため、アイドル判定には使えないと注意しています。Windowsでスクリプトを組むときも、考え方は同じです。

当面の使い方

issueでは、修正案として次の3点が挙がっています。

  • 終わったセッションのCLIを、一定時間アイドルのあとで終了させる
  • 復元しただけで触っていないウィンドウでは、遅延して起動する
  • 使っていないセッションのターミナルペインのシェルを回収する

どれも実装されたという記述はなく、issueはopenのままです。それまでの運用としては、次の組み合わせが実際的です。

  1. 終わったセッションは、その日のうちにアーカイブする
  2. 昼と夕方にセッションプロセスの個数を数え、30個を超えたら再起動の時機と考える(この数は目安で、環境で変わります)
  3. メモリが少ないマシンでは、1日の終わりにアプリを終了する
  4. Gitのグローバル設定に core.fsmonitor=true を入れているなら、いったん外して様子を見る

メモリ7.8GBのマシンでは、システム全体の使用率が98.7%に達してページングが激しくなり、ページファイルが21.5GBまで膨らんだと報告されています。RAMが潤沢なマシンでは気づきにくく、動作が重くなって初めて表に出る性質の問題です。

関連する症状との切り分け

claude.exe の増加と似て見える別件もあります。切り分けの表を置きます。

見えているもの疑う先
--output-format stream-json 付きの claude.exe が個数で増える疑う先この記事の蓄積
find.exe が1コアを使い続ける疑う先find.exeが残るWindowsの確認と後始末
1つのプロセスが数十GBまで膨らむ疑う先Claude Codeのメモリリーク

まとめ

Windowsのデスクトップアプリでは、触ったセッションごとに claude.exe が1つ起動し、アーカイブかアプリ終了まで残ります。見分けは --output-format stream-json の有無で、個数はPowerShellで数えられます。

掃除は、アーカイブ、アプリの再起動、アプリ終了後の残留シェル削除の順に影響が大きくなります。効き目が版で割れているため、アーカイブ後に個数を確かめる手順が欠かせません。根本の修正はまだ出ておらず、当面は日々のアーカイブが最も手軽な予防です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →