Claude Codeでスリープできない原因 — Windowsの電源要求とLinuxの抑止
Claudeを開いたままPCが眠らないとき、Windowsはpowercfg /requests、Linuxはidle時間で切り分けます。issue #98794・#89110の症状と、設定で止まらない点、残るプロセスの閉じ方を書きます。
Claudeを起動したまま席を離れ、戻ってみるとPCがスリープに入っていない。電源設定は何も変えていないのに、アプリを閉じたときだけ眠る。この症状が、WindowsとLinuxの両方でGitHubに報告されています。
Windowsのissue #98794は「アイドルが1時間続いても電源要求を出し続ける」、Linuxのissue #89110は「抑止の登録と解除を繰り返し、アイドル時間が積み上がらない」という別々の仕組みです。どちらもissueはopenで、修正バージョンは示されていません。以下では、症状の見分け方と、報告者が確認した原因、いま手元でできる対処を順に書きます。
どのアプリの話か
issueが立っているのは anthropics/claude-code のリポジトリですが、報告の中身はターミナルで動く claude コマンドそのものとは限りません。
- #89110は冒頭で「Claude Code CLIではなくLinux版Claude Desktopの報告」と断っています。Desktop専用の公開トラッカーが無いため、このリポジトリに立てたという説明です
- #98794の報告者は「Claudeに『Keep computer awake while Claude works』という設定がある」と書いています。この名前の設定はデスクトップアプリのもので、同じ名前をLinuxの#94420も使っています
- #98794はプラットフォーム欄が「Anthropic API」、OSがWindowsで、どちらのアプリが電源要求を出しているかは本文に書かれていません
つまり「CLIがスリープを妨げる」という確証は、いまのところ報告に出ていません。一方でデスクトップアプリのCode機能を使う人は、同じ「Claude Code」という名前でこの症状に出会います。確認の手順は、アプリの種類を問わず使えます。
Windowsで電源要求を確認する
Windowsは、アプリやドライバが「画面を消さないで」「スリープしないで」と求める仕組みを電源要求(Power Request)と呼びます。Microsoftのドキュメントによれば、powercfg /requests はこの一覧を表示するコマンドで、電源要求は画面の自動消灯や低電力スリープへの移行を妨げます。
powercfg /requests出力はカテゴリ別に分かれ、該当するものがなければ None. と出ます。Claudeが原因なら、SYSTEM: など眠りを妨げる区分に、Claudeのプロセスやその親プロセスの名前が並びます。権限エラーが出る場合は、管理者として開いたターミナルで実行してください。
#98794の報告者は、デバッグツールにClaudeが電源要求として現れ、しかもアイドルが1時間続いても残っていたと書いています。HIDデバイス(自作コントローラーの開発用)がHIDバスを占有してスリープを妨げる環境だったため、スリープの妨げがClaudeによるものだと示す材料として、この表示を挙げています。
切り分けの順序
- Claudeを起動していない状態で
powercfg /requestsを実行し、何も出ないことを確かめる - Claudeを起動し、何もさせずに数分置いてからもう一度実行する
- Claudeに現れたら、アプリを終了して再度実行し、一覧から消えるかを見る
3で消えれば、スリープを妨げていたのはClaude側です。消えなければ、USB機器やほかのアプリの電源要求が残っています。#98794の報告者のように、周辺機器が絡む環境では1の時点で別の名前が出ることもあります。
一覧に出たものを個別に無効化する
powercfg /requestsoverride を使うと、特定のプロセスやサービスの電源要求を、OS側で無視させられます。呼び出し元の種別と名前は powercfg /requests の出力から取り、display system awaymode の中から無視する種類を指定します。
# 構文: powercfg /requestsoverride <process|service|driver> <名前> <種類>
# Microsoftのドキュメントの例(wmplayer.exe のdisplayとsystemを無視)
powercfg /requestsoverride process wmplayer.exe display system
# 現在の上書き設定を一覧する(引数なし)
powercfg /requestsoverrideこの上書きがClaudeの電源要求に効くかどうかは、issueでは検証されていません。ドキュメントが示すのは一般的な使い方で、名前にはClaude側が出す呼び出し元の名前(powercfg /requests の出力そのまま)を入れます。副作用もあります。Claudeの電源要求を無視させると、Keep computer awakeを有効にしていてもPCが眠る可能性があります。スケジュールタスクはPCが起きている間しか動かないため、タスクを使う人には逆効果になりえます。
Linux Desktopで起きること
#89110は、Ubuntu/DebianのGNOME環境でClaude Desktopを開いたままにすると自動サスペンドが働かない、という報告です。報告者が突き止めた仕組みは、少し意外な形をしています。
- Claude Desktopはアイドル中でも、セッションマネージャーに対し
flags=4(サスペンドのビット)、理由Electronのinhibitorを登録しては解除し続ける flags=4は「サスペンドの前に通知してほしい」という要求で、サスペンドそのものを止める要求ではない- 問題は登録と解除の繰り返し(チャーン)で、GNOMEは抑止状態が変わるたびにアイドルカウンターを0に戻す。そのため、カウンターが自動サスペンドのしきい値まで積み上がらない
- 同じinhibitorを登録したまま保持し続けると、報告者の観察ではカウンターは20分以上正常に増えた
報告者のログでは、アプリを起動した状態だとアイドル時間の最大が4.9分で、サスペンドは起きませんでした。アプリを閉じると44.5分まで伸び、45分のしきい値でサスペンドしています。再起動すると、また眠れなくなりました。
手元で再現して確かめる
報告に書かれたコマンドをそのまま使えば、自分の環境で同じ現象か確かめられます。
# GNOME Mutterのアイドル時間(ミリ秒)を読む
gdbus call --session --dest org.gnome.Mutter.IdleMonitor \
--object-path /org/gnome/Mutter/IdleMonitor/Core \
--method org.gnome.Mutter.IdleMonitor.GetIdletime
# Inhibit / Uninhibit の呼び出しを監視する
dbus-monitor --session "member='Inhibit'" "member='Uninhibit'"操作せずに待ち、アイドル時間が数分から30分ほどで0に戻るなら、同じ症状の可能性があります。dbus-monitor の出力に /usr/bin/claude-desktop の Inhibit が現れ、その時刻にカウンターが戻っていれば、報告と同じ構図です。自動サスペンドの設定(「設定 > 電源 > 自動サスペンド」)は、事前に有効にしておく必要があります。
原因の候補はkeep-awake
#89110のコメントには、ログから原因を特定した報告が2件あります。Ubuntu 26.04のGNOME Waylandで、Claude Desktopのログに次のような行が出たというものです。
[keep-awake] started (id=28, claims=remote_tools)
[remote-tools-device] keep-awake held (pss=0)
[keep-awake] stopped (id=28): last claim remote_tools released1件目の報告では、何もしていなくても約300秒の保持が25〜30分ごとに繰り返され、保持の開始と解除のたびにアイドル時間が0に戻りました。2件目は、約30分ごとに資格情報を更新する際の get_device_info への応答で保持が始まり、5分で解除される経路を示しています。しきい値が30分なら、サイクルがそれと重なってサスペンドは永遠に起きません。
注目すべきは、設定を切っても止まらない点です。どちらの報告者も、claude_desktop_config.json の ccKeepAwakeWhileWorking を false にし、Remote Controlも切った状態で再現しています。2件目は、起動時に remote-tools-device の初期化が走るのを確認し、サーバー側で有効化されている可能性を挙げています。この点は報告者の推測で、公式の説明はありません。
設定で止まるもの、止まらないもの
デスクトップアプリの公式ドキュメントには、Keep computer awakeをSettings > This computer > Systemで有効にできると書かれています。用途はスケジュールタスクです。タスクはアプリが起動していてPCが起きている間だけ実行され、スリープを跨ぐと実行がスキップされます。それを避けるための設定で、ノートPCの蓋を閉じるとスリープする点は変わりません。
この前提は、スリープが妨げられる理由を考えるうえで大事です。設定を有効にしている間は、スリープを妨げるのが仕様だからです。
| 状況 | 設定の影響 | 報告での扱い |
|---|---|---|
| 設定を有効にしてスケジュールタスクを使う | 設定の影響眠らないのが意図した動作 | 報告での扱い公式ドキュメントどおり |
| Linuxで、Code実行後に保持が残る | 設定の影響設定が有効のとき、再接続したセッションの保持が解放されない | 報告での扱い#94420(openのバグ) |
| Linuxで、設定を切ってもkeep-awakeが周期的に出る | 設定の影響設定が効いていない | 報告での扱い#89110のコメント |
| Windowsで、アイドル1時間でも電源要求が残る | 設定の影響設定の有無は報告に書かれていない | 報告での扱い#98794 |
macOSで、NoIdleSleepAssertion が48時間以上残る | 設定の影響アプリを終了するまで解放されない | 報告での扱い#96015 |
#94420は、「Keep computer awake while Claude works」を有効にしたLinuxで、アプリを終了して再起動した後に再接続されたセッションが保持を握ったままになり、数時間サスペンドできないという報告です。ログには code session hold taken (turn, ...) のあとに解放の行が出るのが通常ですが、再接続の経路では解放されなかったとあります。
終了後にプロセスが残るとき
#89110にはもう1つ、アプリのメニューから終了しても claude-desktop のプロセスが多数残り、pkill -f claude-desktop を実行するまでinhibitorの出し入れが続くという報告があります。「閉じたのに眠れない」場合は、プロセスの残りを疑います。
# 残っているプロセスを確認する
pgrep -af claude-desktop
# 残っていれば終了させる(報告者が使った方法)
pkill -f claude-desktoppkill は名前に claude-desktop を含むプロセスをすべて止めます。保存していない作業が残っていないか、アプリ側で確認してから実行してください。実行後にアイドル時間が積み上がるようになれば、原因はClaude Desktopです。報告者はこの手順で、再びサスペンドが働いたことを確かめています。Windowsで孫プロセスが残る別の症状は、Claude Codeでfind.exeが残るWindowsの確認と後始末が扱っています。
修正が出るまでに手元でできる対処
公式の修正は、報告の時点では出ていません。手元で選べる手段は次のとおりです。
- 使わない時間は、アプリを終了する。Windowsは終了後に
powercfg /requestsで消えたかを確認する。Linuxはプロセスが残っていないかをpgrepで見る - Linuxでは、アプリを閉じたうえで
pkill -f claude-desktopを併用する - スケジュールタスクを使わないなら、Keep computer awakeは切っておく。ただしLinuxの報告では、切っても保持が出る経路がある
- Windowsで他の機器が絡む場合、まず
powercfg /requestsの一覧でClaude以外に要求が出ていないかを見る - 一定時間後に確実に眠らせたいPCなら、電源設定を信じず、使い終わったらアプリを終了する運用が確実
Remote Controlのスリープ挙動に関心がある場合は、Remote Controlが20分放置で切断される原因と回避策に、スリープと切断の関係が整理されています。Linux版のインストールや再ログインの問題は、Claude Desktop Linux版(beta)のインストール手順とClaude Desktop Linux版で再ログインを繰り返し求められる原因と対処法が参考になります。
まとめ
スリープできない原因は、アプリが出す電源要求や抑止の仕組みにあります。Windowsは powercfg /requests、Linux(GNOME)はアイドル時間と dbus-monitor で、Claudeが関与しているかを切り分けられます。報告に出ているのは主にデスクトップアプリで、設定を切っても周期的な保持が残る例があり、修正はまだ示されていません。アプリを終了してから確認する手順が、いちばん確実な切り分けです。