Claude DesktopのWaylandで自動ロックが効かない原因と確認法
LinuxのWaylandでClaude Desktopを起動していると、画面の自動ロックや消灯が働かない報告があります。原因の見立て、抑止の確認コマンド、今できる回避策をまとめます。
Linux版のClaude DesktopをWaylandで動かしていると、離席しても画面が暗くならず、自動ロックも始まらないことがあります。GitHubには、GNOME、KDE、labwcの3環境から同じ症状の報告が出ています。共通するのは、Claude Desktopがアイドル抑止(idle inhibitor)を握り続けるという点です。
原因はアプリの設定画面だけでは切り分けられません。この記事では、報告の内容、いま握られているかを確かめるコマンド、設定を切っても直らないケースの扱い、回避策を順に書きます。
症状は「ロックしない」だけではない
issue #99362(GNOME Wayland)の報告者は、症状を2つに分けています。
- 設定したアイドル時間(
idle-delay、報告では420秒)が過ぎても、自動ロックと消灯が起きない - ロック中に通知で画面が起きると、そのまま点きっぱなしになる
2つ目は見落としやすい症状です。ロック画面に出るClaudeの通知が画面を起こし、その後は入力がなくても消えません。通知のたびに点いたり消えたりする挙動も報告されています。
報告者の計測では、ロック中でもidleの秒数が420秒を超え、idle-delayを過ぎた後も画面は点いたままでした。ロックされていない状態でも、アイドル時間が421秒に達するまでプレゼンス(在席状態)はavailableのままで、画面は消えませんでした。
握っているのはClaude Desktop本体
GNOMEではgnome-session-inhibit --listで現在の抑止を一覧できます。報告ではこう表示されています。
mutter: idle-inhibit (idle)
/usr/bin/claude-desktop: Electron (suspend)1行目が画面のアイドルを止めているものです。名前がmutterなので、Claudeだとは気づきにくい点に注意してください。2行目はスリープ抑止で、役割が別です。
報告者はClaude Desktopだけを終了して再起動し、犯人を絞っています。終了するとアイドル抑止が消え、起動の約4秒後に再び現れました。他のアプリを順に閉じても消えなかったので、原因はClaude Desktopと判断されています。
自分の環境で確かめる
GNOMEなら、次の2コマンドで足ります。
gnome-session-inhibit --list
gsettings get org.gnome.desktop.session idle-delay1つ目でmutter: idle-inhibitが出ていて、Claude Desktopを終了すると消えるなら、同じ症状です。2つ目は自動ロックまでの時間で、uint32 420のように秒数が返ります。
KDE Plasma 6のWaylandでは、一覧に頼れません。#104923の報告者によると、PowerDevilのListInhibitionsは画面だけを止める抑止を表示しないため、バッテリーのウィジェットには何も出ないまま画面が止まります。報告者はext_idle_notifier_v1に10秒のタイマーを2つ登録しました。抑止を考慮する通知と、入力だけを見る通知です。作業中のセッションがあるときに後者だけが発火すれば、入力がないのに抑止が効いています。次にアプリのウィンドウを最小化して、10秒以内に前者も発火するかを見ると、ウィンドウが握っているかどうかを切り分けられます。
GNOMEとKDE以外では、この一覧に出ません。labwcとswayidleの環境の報告者は、systemd-inhibit --listに何も出なかったと書いています。代わりに、入力のみを見る通知(ext_idle_notifier_v1のinput-idle)は発火し、抑止を考慮する通常の通知は発火しない、という差で見分けています。
設定を切っても直らない例と、直った例
ここに食い違いがあります。2つの報告で、設定の効き方が逆です。
「Keep computer awake while Claude works」を切った結果
切ると直った
設定をオフにしたらKWinの通知が10秒以内に発火しました。オンのままでは発火しませんでした。
切っても直らなかった
設定を無効にして再起動しても、起動時のログ行[keep-awake] startedが再び出ました。
#99362のGNOME報告者も、設定のどれも効かないと書いています。確認した項目にはkeep_awake_while_working、keep_awake_on_battery、通知レベル、claude_desktop_config.jsonが含まれます。
一方で#104923のKDE報告者は、設定を切ると直ったと報告しています。Claudeのバージョンも違い、前者は2.9939.4、後者は3.6556.2です。環境やバージョンで挙動が分かれている可能性はありますが、原因が1つとは書かれていません。
ログで起動時の保持を見る
#99362のコメント(labwc、Claude Desktop 2.42304.0)は、ログに手がかりがあると指摘しています。
grep keep-awake ~/.config/Claude/logs/main.log起動のたびに[keep-awake] started (id=0, claims=keepAwakeEnabled)が出て、対応するstoppedが一度も出ないのが問題の形です。コメント主は、2026-10-08ごろまでのバージョンでは、claim(保持の理由)ごとにブロッカーが開始と停止を繰り返していたと書いています。このため回帰(以前は動いていた挙動の退行)ではないかと推測しています。
原因の見立て: Chromiumが画面側の抑止にしている
#99362の報告者は、アプリ内でpowerSaveBlocker.startが使われているのは"prevent-app-suspension"だけだと調べています。これはスリープ抑止の種類で、画面を点けておく指定ではありません。
#99362のコメントがたどった先が、Chromiumの修正コミットです。コミットメッセージはこう説明しています。
- Linuxの
PowerSaveBlockerは、kPreventAppSuspensionを含むすべての種類でスクリーンセーバーを止めていた - Waylandでは、スクリーンセーバーの停止が、フォーカス中のウィンドウへの
zwp_idle_inhibitor_v1になる - その結果、ディスプレイがアイドルにならない。ウィンドウを最小化すれば解除される
修正は、画面を点けておく種類のロックにだけスクリーンセーバーの停止を適用する内容です。スリープ抑止はD-Bus経由で従来どおり働きます。コミットメッセージは、Waylandが既定になったM141から目立つようになったと書いています。
#104923の報告者も、同じ方向を指す観察をしています。アプリのウィンドウを最小化すると10秒以内に抑止が外れ、元に戻すと再び現れました。
直るのはいつか
#99362のコメントによると、修正はChromium 157(安定版の予定は2026-11-03)から入り、それ以前のブランチには入りません。Claude Desktop 2.9939.4が使うElectron 44はChromium 152なので、Electronを更新するか、コミットをバックポートする必要があります。どちらが先に来るかは、issueには書かれていません。
加えて、起動時に開始されて止まらないid=0のブロッカーは別の不具合だと、同じコメントは述べています。Chromiumの修正で画面はスリープできるようになっても、システムのサスペンドはこのブロッカーで止められたままです。
今できる回避策
回避策は影響の大きさで選びます。
| 状況 | 回避策 | 注意 |
|---|---|---|
| KDE Wayland | 回避策設定の「Keep computer awake while Claude works」をオフ | 注意#104923では直ったが、#99362では無効だった |
| ロック画面の点灯だけ困る | 回避策show-in-lock-screenをfalseにして通知を隠す | 注意起きる原因は減るが、抑止そのものは残る |
| どの環境でも | 回避策Claude Desktopを使わないときは終了する | 注意確実だが、バックグラウンド動作も止まる |
| 作業中の短時間 | 回避策ウィンドウを最小化する | 注意#104923で抑止が外れたと報告 |
#99362のコメントには、設定画面のClaude Codeの項で「Keep awake on battery power」が表示されなくなったという報告もあります。メインのトグルがオフのあいだは隠れているだけかもしれないと、報告者自身が書いています。項目が見当たらなくても、先に見たログとgnome-session-inhibit --listで抑止の有無を確かめられます。
GNOMEの報告者は、独自のユーザーサービスも作っています。idle-delayに達したらScreenSaver.SetActive(true)を呼び、ロック中で42秒アイドルならPowerSaveMode=3にする内容です。本人も「ユーザーが書くべきものではない」と断っています。
--ozone-platform=x11で起動すれば避けられるかもしれない、という案もissueにはあります。報告者自身が「検証していない」と明記しているので、効くとは言えません。
通知で画面が起きる件との関係
ロック画面で通知が画面を起こす点は、別のissueが絡みます。#99362は、通常の応答でも通知が出る件(#79329)や、スリープ抑止が登録と解除を繰り返す件(#89110)を関連として挙げています。ただし、どれが直接の原因かは報告者も断定していません。
スリープ抑止まわりの切り分けは、Claude Codeでスリープできない原因にまとめた確認手順が使えます。
他のLinux症状との違い
Claude Desktop Linux版には、別の原因による症状もあります。画面ロックと関係がなく、GNOMEで出るダイアログが気になる場合はショートカット許可の止め方が該当します。描画が重い場合はGPUが無効になる原因を先に見てください。
X11のCinnamonでも、似た症状が#83573に報告されています。#99362の報告者は、今回の件をその「Wayland側」と見ています。X11ではD-Busのflags=8の抑止として現れ、理由はCapturingと表示されます。つまりWaylandに限った現象とは限らず、--ozone-platform=x11で避けられると決めつけることもできません。
ロックが効かない症状は、gnome-session-inhibit --listでmutter: idle-inhibitが出るか、ログに[keep-awake] startedが出るかで、今回の件と見分けられます。
まとめ
報告に共通するのは、Claude Desktopが画面側のアイドル抑止を握ったままになる点です。issueのコメントは、ChromiumのWayland実装を主な原因として挙げていて、修正はChromium 157以降に入る予定です。Electron側の更新が来るまでは、設定を切ってみる、使わないときは終了する、の2点が現実的です。設定が効くかどうかは環境で分かれているので、切ったあとにgnome-session-inhibit --listなどで抑止が消えたかを確かめてください。