## Environment - Claude Desktop 2.26454.0 (MSIX, Microsoft Store), Windows 11 Pro 10.0.26200 - Bundled Claude Code 2.1.289, Code tab, local sessions, permission mode Auto ## What happened (2026-10-07, local time EEST) 1. **07:06** – the app installed an idle "stealth update" (2.19675.1 → 2.26454.0). Before quitting it stopped 3 active Code sessions cleanly (`[CCD] Stopping 3 active session(s) on quit`; `SessionEnd` hooks ran). 2. **07:06–07:10** – after relaunch, session-window restore re-ope

[BUG] Desktop (Windows): Code tab sessions restored after an automatic update never get the session idle timeout and keep running for hours

Status Open

Reported on v2.1.289

Maintainer reply None cached

Activity 1 comment · opened Oct 7, 2026

Environment

Claude Desktop 2.26454.0 (MSIX, Microsoft Store), Windows 11 Pro 10.0.26200
Bundled Claude Code 2.1.289, Code tab, local sessions, permission mode Auto

What happened (2026-10-07, local time EEST)

07:06 – the app installed an idle "stealth update" (2.19675.1 → 2.26454.0). Before quitting it stopped 3 active Code sessions cleanly ([CCD] Stopping 3 active session(s) on quit; SessionEnd hooks ran).
07:06–07:10 – after relaunch, session-window restore re-opened two of those sessions ([CCD] Warming session local_…). I did not open them myself.
For these restored sessions main.log shows only [WarmLifecycle:preview] Starting idle timeout for local_…: 1800s. It never shows [WarmLifecycle:session] Starting idle timeout for local_…: 900s. That day the session-level line appears only for a scheduled-task session, which was paused normally ([CCD] Pausing session local_… (idle_timeout)).
As a result, the restored sessions' claude.exe processes (claude-code\2.1.289) stayed alive about 13 hours while hidden and idle. They kept their cross-session inbox (ListAgents listed them as live peers), but the sidebar did not show them as active. A third old session (started 07:57, cause unknown) behaved the same way.
The processes had to be ended manually.

Expected

A restored session that stays hidden and idle is paused after the session idle timeout (900 s, arm=when-hidden), like any other session.

Actual

No session-level idle timer is armed for sessions restored after an update, so their CLI processes never stop until the app is restarted or the processes are killed.

Notes

Related changelog entries: v1.26832.0 (session-window restore), v2.2553.0 (update restarts shut sessions down like quitting).
Possibly related to the stealth-update path in #92141 (different symptom).
Question: is there an official way to close a Code tab session (stop its process) without archiving it?

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗