[BUG] Desktop (Linux): "Keep computer awake while Claude works" hold is never released after a re-adopted or stalled Code session, blocking idle suspend for hours

### Preflight Checklist

- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code

### What's Wrong?

With **"Keep computer awake while Claude works"** enabled, Claude Desktop takes a keep-awake hold per Code turn and normally releases it when the session goes idle:

```
[keep-awake] code session hold taken (turn, battery=false)
[keep-awake] code session hold released (idle, held 166725ms)
```

In two paths the hold is instead kept after no Code session is doing anything. On Linux the hold is a GNOME session-manager inhibitor (app id `/usr/bin/claude-desktop`, flags `4` = suspend), so GNOME's automatic idle suspend never fires for as long as it is held.

**Case 1 — a hold taken when a session is re-adopted is not released when its turn completes (reproduced on demand).**
I quit Claude Desktop while a remote (SSH) Code session was mid-turn, then relaunched it. On launch the app re-adopted the session and took a hold at 10:59:05. The re-adopted turn completed at 10:59:31, and the only other Code turn ended at 11:00:12. From 11:00:12 to 11:07:04 no Code turn was running in any session, yet the hold was neither released nor stopped, and the GNOME inhibitor stayed in place. In the same app session, before the relaunch, ordinary holds were released 118 s and 174 s after taking them (log below). In an earlier unattended occurrence the same re-adoption hold lasted 4h38m, 3h24m of it after the session had finished, and ended with reason `armed_grace` rather than `idle`.

**Case 2 — a session is dropped as "stalled" but the hold is never released (observed once, not yet rechecked on this version).**
A hold started at 23:42:14 from a Code session turn, and Code sessions legitimately kept it through the night: a remote (SSH) session last wrote to its transcript at ~01:37. At 01:56:20 the app logged that session as "no longer counted (stalled)", but hold `id=25` was never stopped: no `code session hold released` and no `stopped` line follow, and the GNOME inhibitor is still present the next morning. Meanwhile the `remote-tools-device` claims inside the same hold kept being taken and released normally, so only the Code-session claim is keeping the hold alive.

Observable effect in case 2: the last user input was at 01:25, and GNOME was set to suspend after 15 minutes idle. From 01:56, when the stalled session stopped being counted, nothing should have blocked suspend, but GNOME never suspended because the inhibitor was still held. The machine only suspended at 02:15, through a separate root cron job that doesn't honour GNOME session inhibitors.

### What Should Happen?

The Code-session claim should be released as soon as no Code session is mid-turn:

- when a re-adopted session's turn completes (case 1), the same way an ordinary turn's hold is released;
- when a session is dropped from the count as stalled, the hold should be re-evaluated and released if nothing else claims it (case 2).

### Error Messages/Logs

Timestamps are local time. Session IDs are replaced with placeholders; other lines are unrelated and omitted.

**Case 1** (`main.log`; every keep-awake, app-start, re-adoption and turn-completion line in the window):

```
10:51:59 [info] [keep-awake] started (id=0, first claim=code_turn)
10:51:59 [info] [keep-awake] code session hold taken (turn, battery=false)
10:53:57 [info] [keep-awake] stopped (id=0, last claim=code_turn)
10:53:57 [info] [keep-awake] code session hold released (idle, held 118291ms)
10:54:50 [info] [keep-awake] started (id=1, first claim=code_turn)
10:54:50 [info] [keep-awake] code session hold taken (turn, battery=false)
10:57:44 [info] [keep-awake] stopped (id=1, last claim=code_turn)
10:57:44 [info] [keep-awake] code session hold released (idle, held 173828ms)
10:58:26 [info] [keep-awake] started (id=2, first claim=code_turn)
10:58:26 [info] [keep-awake] code session hold taken (turn, battery=false)
<- app quit here, a remote session mid-turn
10:59:01 [info] Starting app {
10:59:04 [info] [SSH] Background re-adoption: re-adopting session 's running Claude Code (mid-turn at quit)
10:59:05 [info] [keep-awake] started (id=0, first claim=code_turn)
10:59:05 [info] [keep-awake] code session hold taken (turn, battery=false)
10:59:31 [info] [Stop hook] Query completed for session
10:59:31 [info] [CCD CycleHealth] healthy cycle for (27s, hadFirstResponse=true)
11:00:12 [info] [Stop hook] Query completed for session
<- no Code turn running anywhere from here until ~11:07:04
11:07:45 [info] [Stop hook] Query completed for session
```

No `code session hold released` and no `[keep-awake] stopped (id=0 …)` after 10:59:05.

**Case 2** (main instance's `main.log`, complete `keep-awake` lines for the period):

```
2026-09-14 23:40:32 [info] [keep-awake] stopped (id=24, last claim=code_turn)
2026-09-14 23:40:32 [info] [keep-awake] code session hold released (idle, held 67026ms)
2026-09-14 23:42:14 [info] [keep-awake] started (id=25, first claim=code_turn)
2026-09-14 23:42:14 [info] [keep-awake] code session hold taken (turn, battery=false)
2026-09-14 23:58:29 [info] [remote-tools-device] keep-awake held (pss=0)
2026-09-15 00:04:14 [info] [remote-tools-device] keep-awake released (quiet, held 344562ms)
... (same held/released pair every ~10–30 min) ...
2026-09-15 01:52:43 [info] [remote-tools-device] keep-awake held (pss=0)
2026-09-15 01:56:20 [warn] [keep-awake] session no longer counted (stalled)
2026-09-15 01:57:43 [info] [remote-tools-device] keep-awake released (quiet, held 300001ms)
2026-09-15 10:15:50 [info] [remote-tools-device] keep-awake held (pss=0)
2026-09-15 10:20:50 [info] [remote-tools-device] keep-awake released (quiet, held 300000ms)
```

No `code session hold released` and no `[keep-awake] stopped (id=25 …)` after 23:42:14.

The GNOME inhibitor still present the next morning:

```
$ gdbus call --session --dest org.gnome.SessionManager \
--object-path /org/gnome/SessionManager/Inhibitor159 \
--method org.gnome.SessionManager.Inhibitor.GetAppId
('/usr/bin/claude-desktop',)
$ gdbus call ... --method org.gnome.SessionManager.Inhibitor.GetFlags
(uint32 4,)
```

### Steps to Reproduce

Case 1 (reproduced deliberately):
1. Enable "Keep computer awake while Claude works".
2. Start a Code session on a remote host over SSH and send a prompt that takes a while.
3. Quit Claude Desktop while that turn is still running, then relaunch it.
4. The session is re-adopted ("mid-turn at quit") and a hold is taken.
5. Let the turn finish and don't start any other turn.
6. The hold and the GNOME inhibitor remain, well past the ~2–3 minutes an ordinary hold takes to release.

Case 2 (observed, not deliberately reproduced):
1. Enable the setting and run a long task in a remote (SSH) Code session.
2. Leave the machine unattended until the task stops making progress.
3. The session is logged `no longer counted (stalled)`.
4. The hold started by the first turn is never stopped. Check with `gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager --method org.gnome.SessionManager.GetInhibitors`.

### Claude Model

Opus

### Is this a regression?

I don't know

### Claude Code Version

2.1.270 (Claude Desktop 1.52386.6, `claude-desktop` .deb package)

### Platform

Anthropic API

### Operating System

Ubuntu/Debian Linux (Pop!_OS 22.04, GNOME Shell 42.9, X11 session)

### Terminal/Shell

Other: Claude Desktop app (Code tab)

### Additional Information

- Closest earlier report: #45769 (macOS, an Electron `NoIdleSleepAssertion` held from launch until quit). That was closed as not planned, and it predates the per-turn keep-awake claims shown above. This report is about those claims failing to release in two specific paths.
- Distinct from #92010 (a Remote Control hold *not restored* after relaunch). Here a hold is taken on relaunch and *never released*.
- On Linux the only user-visible symptom is that the desktop never idle-suspends. Nothing in the UI shows that the hold is still active, so it is easy to misattribute.