[BUG] Claude Desktop (Linux/GNOME Wayland): holds a Wayland idle inhibitor while idle — idle auto-lock never fires and a woken lock screen never powers off

Status Open

Maintainer reply None cached

Activity 0 comments · opened Oct 4, 2026

Summary

On GNOME Wayland, Claude Desktop holds a Wayland idle inhibitor (zwp_idle_inhibitor_v1) for as long as it runs, including when it is idle. GNOME lists it as mutter: idle-inhibit (idle), not under /usr/bin/claude-desktop, so it is hard to trace back to Claude. While it is held, GNOME's session can never become idle. That causes two problems:

Idle auto-lock and blanking never happen. The idle-delay timeout (420 s here) never fires while the desktop is unlocked.
A woken lock screen never turns off again. Claude's own notifications wake the lock screen. Once woken, the monitor stays on indefinitely. Before that, it cycles on and off while locked as each notification arrives.

The app's own settings don't control this. "Keep computer awake while Claude works" only takes a suspend inhibitor. This looks like the Wayland side of #83573, which shows the same idle inhibit on X11/Cinnamon as a D-Bus flags=8 inhibitor with reason Capturing.

Environment

Claude Desktop 2.9939.4 (Linux .deb), Electron 44.4.3 / Chromium 152.0.7977.130, running natively on Wayland
Ubuntu 26.04.1 LTS, GNOME Shell 50.1 (Wayland), two monitors
org.gnome.desktop.session idle-delay = 420 s, lock-enabled=true
Claude notifications: GNOME defaults (banners on, shown on the lock screen). Claude Code tab notification settings are at their defaults (banners).

1. Claude Desktop is the holder (confirmed)

The other apps stayed running the whole time; only Claude Desktop was quit and relaunched.

# Claude Desktop running
$ gnome-session-inhibit --list
mutter: idle-inhibit (idle)
/usr/bin/claude-desktop: Electron (suspend)
/usr/lib/chatgpt/ChatGPT: Electron (suspend)

# 03:13:02 SIGTERM to the Claude Desktop main process; 0 claude-desktop processes at 03:13:10
# 03:13:12
/usr/lib/chatgpt/ChatGPT: Electron (suspend)        <- idle inhibitor gone

# 03:15:38 relaunched (gtk-launch com.anthropic.Claude)
03:15:38  mutter idle-inhibit: absent
03:15:43  mutter idle-inhibit: present              <- back ~4 s after launch, no user action

How the holder was narrowed down:

Closing other apps one at a time (Chrome, Telegram, Thunderbird, Antigravity, Remmina, an overlay helper) never removed the inhibitor.
I matched peer sockets of /run/user/1000/wayland-0 to find the remaining native Wayland clients. Apart from Claude Desktop, those were:
a Tauri/WebKitGTK app with no zwp_idle_inhibit code
GNOME and snap background services with no mapped window
ChatGPT runs under XWayland, so it cannot hold this inhibitor.
The inhibitor also stays when every Claude window is moved to an empty workspace.

2. Effects (confirmed)

2a. A woken lock screen stays on. I locked with Super+L at about 03:19:25. A Claude notification appeared on the lock screen and woke the display (I have a photo). After that, with no input:

time      PowerSaveMode  Presence   idle_s  ScreenSaver.GetActive  logind LockedHint  mutter idle-inhibit
03:22:18  0 (on)         0 (avail)  154     false                  yes                present
03:24:48  0 (on)         0 (avail)  305     false                  yes                present
03:26:48  0 (on)         0 (avail)  425     false                  yes                present   <- past idle-delay
03:27:48  0 (on)         0 (avail)  485     false                  yes                present

org.gnome.SessionManager.IsInhibited(8) returns true, and Claude's mutter: idle-inhibit is the only idle-flag inhibitor.
Presence never becomes idle, so GNOME never re-blanks the woken lock screen.
ScreenSaver.GetActive reports false while the session is still locked (LockedHint=yes).
Calling ScreenSaver.SetActive(true) in this state has no effect.

2b. Locked but not woken works. If nothing wakes the locked screen, the monitor powers off after about 5 s, with or without Claude Desktop.

2c. On-off cycling while locked. Before I measured this, the visible symptom was the monitor turning on and off repeatedly while locked. It woke with each Claude notification and eventually stayed on, as in 2a.

2d. Unlocked idle. For the same reason, GNOME's idle-delay auto-lock and blanking cannot fire while the inhibitor is held, because Presence stays available. Measured unlocked, with no input: Presence stayed available (0) and the display stayed on through 421 s of idle time (idle-delay 420 s). Nothing happened until my workaround service (below) called ScreenSaver.SetActive(true) at 420 s. GNOME then blanked the display within ~5 s and the session showed LockedHint=yes ~16 s later.

3. Related observation (not attributed)

Over the ~62 h session, gnome-session created 10,357 inhibitor objects, about one every 21 s. While the desktop was unlocked and idle for 20 s, there were no add/remove events, so the churn is intermittent. I did not attribute it to an app. It may be related to #89110 (Claude registering and releasing its Electron suspend inhibitor repeatedly).

4. Why this looks Chromium-internal, not the keep-awake feature

The only powerSaveBlocker.start call in app.asar uses "prevent-app-suspension". That matches the Electron (suspend) D-Bus inhibitor (flags=4) and the [keep-awake] log lines. Claude Desktop holds no flags=8 D-Bus inhibitor.
No Claude setting affects this. I checked keep_awake_while_working, keep_awake_on_battery, the notification levels and claude_desktop_config.json (keepAwakeEnabled=true).
Chromium's Ozone/Wayland ZwpIdleInhibitManager::CreateInhibitor() creates zwp_idle_inhibitor_v1 on the focused window's root surface. Mutter turns that into Inhibit("mutter", "idle-inhibit") (meta-wayland-idle-inhibit.c).
Chromium 146+ is reported to assert Wayland idle-inhibit on ordinary pages that use no video, audio or Wake Lock: basecamp/omarchy#5092. That fits an inhibitor that appears within seconds of launch.

Expected

When Claude Desktop is idle, with no media, no capture and no Wake Lock request, it should not hold an idle inhibitor.
GNOME's idle-delay should then lock and blank the screen, and a woken lock screen should power off again.

Workarounds I'm using

I turned off Claude's lock-screen notifications (show-in-lock-screen=false for com-anthropic-claude). This removes the most common wake-up, but the inhibitor remains.
I added a user service that re-applies GNOME's idle timing over the inhibitor:
unlocked and idle for idle-delay: call ScreenSaver.SetActive(true)
locked (LockedHint) and idle for 42 s with the display on: set PowerSaveMode=3
on the first input: set PowerSaveMode=0

It works, but users shouldn't need this.

Possible fixes

Find which web contents requests display-sleep prevention at startup and stop it. Alternatively, deny screen Wake Lock permission requests that the app does not need.
Pick up the upstream Chromium fix for the 146+ regression once one exists.
As a stopgap, offer a setting to launch with --ozone-platform=x11. I haven't verified that this avoids the issue.

Related: #83573 (same idle inhibit on X11/Cinnamon via D-Bus Capturing), #89110 (suspend inhibitor churn), #94420 (keep-awake hold not released), #79329 (notifications firing on ordinary responses, which wakes the lock screen).

View original on GitHub ↗