[BUG] Claude Desktop Inhibits Sleep in Linux and Leaves Orphaned Processes When Quit

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Note: this report is about Claude Desktop for Linux, not the Claude Code CLI. Filing here since there is no public tracker for Claude Desktop and other Desktop issues live in this repo.

Related but distinct from #83573. That issue describes a held flags=8 (idle-inhibit) lock with reason Capturing that blocks screen blanking. This one is a cycling flags=4 (suspend) inhibitor that blocks automatic suspend by a different mechanism. Fixing the leaked Capturing lock would not fix this.

Claude Desktop repeatedly registers and releases a session-manager inhibitor (app='/usr/bin/claude-desktop', flags=4, reason='Electron') while sitting idle with no user interaction. GNOME resets Mutter's idle counter on each inhibition-state change, so the idle timer never accumulates enough uninterrupted time to reach the automatic-suspend threshold. The machine never suspends for as long as the app is running.

The flags value is worth stressing, because it makes the cause counterintuitive: the app never requests idle inhibition. flags=4 is the suspend bit, a request to be notified before suspend, not a request to prevent it. The damage comes from the register/release _churn_, not from the inhibit itself. A steadily-held inhibitor causes no problem; I observed the idle counter climbing normally for 20+ minutes while the same inhibitor stayed continuously registered.

What Should Happen?

Either:

1. Register the inhibitor once at startup and hold it, rather than cycling it. A stable inhibitor does not reset the idle counter.
2. Or take it only when there is actual work to protect (an in-flight Cowork task, a running Code session), and not at all when the app is idle in Chat.

Secondary: quitting the app from its own menu leaves numerous claude-desktop processes running, and the inhibitor cycling continues until pkill -f claude-desktop. Users who "quit" the app still cannot suspend.

Error Messages/Logs

Steps to Reproduce

Run Claude Desktop on a GNOME desktop with automatic suspend enabled (Settings → Power → Automatic Suspend).

1. Leave the machine completely untouched, past the suspend threshold.
2. Sample the idle counter periodically:

gdbus call --session --dest org.gnome.Mutter.IdleMonitor --object-path /org/gnome/Mutter/IdleMonitor/Core --method org.gnome.Mutter.IdleMonitor.GetIdletime

1. Observe the counter resetting every few minutes and never reaching the threshold (2700000 ms for a 45-minute setting). The machine does not suspend.
2. Quit Claude Desktop and confirm with pkill -f claude-desktop. Repeat step 2. The counter climbs uninterrupted and the machine suspends normally.

idle-watch.log

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.34493.1 (255293) 2026-08-21T02:05:20.000Z (Desktop, not Code)

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

In reference to the idle-watch.log blob posted above: Single session, one variable toggled twice, everything else held constant. Idle time and registered inhibitors sampled once per minute.

Period        Claude Desktop   Max idle    Resets   Median gap   Suspended?
10:05-11:38   running           4.9 min      73      1.0 min     no
11:39-13:17   CLOSED           44.5 min      49      1.0 min     YES, at 13:17
14:18-14:42   CLOSED           23.4 min       2     24.3 min     (woken at 14:18)
14:43-18:31   relaunched       22.7 min      29      5.0 min     no

The claude-desktop inhibitor is absent from the log in exactly one continuous run, 11:38:48 to 14:42:32, which contains the only suspend of the day. The app was closed at 11:38; the machine reached 44.5 min idle and suspended at 13:17 (45-minute threshold). It was relaunched at 14:42; the reset pattern resumed immediately and the machine did not suspend again in the following four hours.

An earlier 7.5-hour session with the app running throughout: 68 resets, median gap 6.1 min, longest clean stretch 20.8 min, zero stretches over 45 min, zero suspends.

The inhibitor is present in only 17–23% of samples during periods when the app is running, which is the churn made visible; it is registering and releasing constantly rather than holding.

D-Bus trace correlating resets to the calls

Idle-counter resets line up to the second with Inhibit/Uninhibit calls:

13:10:38  Uninhibit from :1.124        -> idle counter reset at 13:10:38
13:16:49  Inhibit  '/usr/bin/claude-desktop' flags=4 reason='Electron'
                                       -> idle counter reset at 13:16:49

Captured with:

dbus-monitor --session "member='Inhibit'" "member='Uninhibit'" "member='SimulateUserActivity'"

[keep-awake] started (id=28, claims=remote_tools)
[remote-tools-device] keep-awake held (pss=0)
... 5 minutes later ...
[keep-awake] stopped (id=28): last claim remote_tools released
[remote-tools-device] keep-awake released (quiet, held 300000ms)