Repository navigation
[BUG] Active session auto-archives within seconds of window focus loss (Windows) #57602
Description
Activity
- changed the title
[-]Active session auto-archives within seconds of window focus loss (Windows)[/-][+][BUG] Active session auto-archives within seconds of window focus loss (Windows)[/+]on May 9, 2026 Found 3 possible duplicate issues:
- Desktop app: chats moved from Archived back to Active are auto-archived again after ~1 second #57586
- Desktop app (Windows): background sessions pause and timer resets when switching to another session #48045
- [BUG] Archived Code sessions not visible in Archive filter on Claude Desktop (Windows) #24534
This issue will be automatically closed as a duplicate in 3 days.
- If your issue is a duplicate, please close it and 👍 the existing issue instead
- To prevent auto-closure, add a comment or 👎 this comment
🤖 Generated with Claude Code
What happened (corrected)
Active session auto-archives after ~3 minutes of user idleness, with Claude Code Desktop in foreground focus. Initially suspected this was focus-loss-triggered, but observed it occurring while the app remained the active window — user simply stepped away from the keyboard. The assistant was actively generating a response at the time of archival.
Revised repro
- Start a Claude Code Desktop session
- Have a multi-turn conversation (~hours-old session)
- Stop typing — leave the app in focus, do not interact for ~3 minutes
- Return
Expected: session is exactly where I left it.
Actual: session pane shows "This session is archived, to restart it, click unarchive."Reproduced twice today within minutes. Not focus-related; idle-only.
+1, hitting this exact behavior on Windows 10 Home 19045.6466 with Claude Code Desktop running Opus 4.7.
Frequency in one continuous work session today (2026-05-11): auto-archived 3 times during a single project conversation. Each time required clicking Unarchive to continue.
Specific trigger pattern I noticed:
The archives all happened during periods where Claude was waiting on long-running background tasks — specificallygh pr merge --autowaiting on a Codex Cloud audit (~3-5 min each) andcodex exec reviewruns (~4 min each). During those waits the user (me) tab-switches to read other things, returns, and the session is archived. So the focus-loss trigger noted in the original report seems compounded by long quiet periods on the assistant side.Conversation state preservation: confirmed intact. Unarchiving restores the full multi-turn conversation, including pending tool results. So this really does feel like a UI pointer issue, not a state loss issue.
Workaround that helped me a bit: typing any short message (even "ok" or "รอก่อน") before tab-switching seems to defer the archive. Doesn't always work though.
Happy to share session UUIDs privately to Anthropic engineering if useful — just say where to send them.
+1, hitting same behavior on MacOS with Claude 1.6608.2 (ebf1a1) 2026-05-08T23:17:27.000Z
Hitting exact behavior with MacOS Claude Claude Code 2.1.138. 2026-08-11 19:39:33 UTC.
+1, getting same behavior however happening within minutes of not interacting with the session. Running - Version 1.7196.0 of Claude desktop
+1 getting this issue over and over on my windows 11 pro machine (Version 1.7196.0)
+1 getting this issue since the last Update to Version 1.7196.0
+1 macOS — same signature, fresh evidence.
Environment
- Claude Code 2.1.119 (Code, not Desktop)
- macOS 26.3.1 (build 25D2128), arm64
- Shell: zsh
- No
archive/idle/timeoutkeys in~/.claude/settings.json; noarchive_sessioncall anywhere in user hooks or installed plugins.
Reproduction (yesterday, 2026-05-14, same workday, three sessions, no operator action)
Session JSONL UUID prefix Started (UTC) Stop hook fired (UTC) Last event (UTC) Gap to next session 19785470…14:38:46 18:25:03 18:29:03 19 min 68c50669…18:48:35 19:34:41 19:38:03 23 min 098970e4…20:01:16 23:31:47 23:32:55 — All three sessions ended with a clean
stop_hook_summary subtype=stop_hook_summary hookCount=4event — i.e., the harness fired Stop cleanly, not a crash. The JSONLs on disk are intact and resumable. The operator did not run/clear//compact/ close terminal at any of these moments and was mid-conversation each time. This matches @eddyafram's corrected analysis ("~3 min idle, app foregrounded") and the macOS confirmations from @acyberduck and @allhuggermugger.Diagnostic plumbing added on my side to confirm signature on next occurrence
To verify whether each Stop fires at
hid_idle_seconds >= ~180while Claude is the frontmost app (the #57602 signature), I added a diagnostic capture block at the end of my session-end Stop hook that logs the following per fire to a local file (~/.claude/stop-trigger-diagnostics.log):hid_idle_seconds(fromioreg IOHIDSystem)frontmost_app(osascript)pm_assertions,claude_procs,power_state,network,session_id_env,parent_pid,tty
Code: adminwat/waterlux-claude-config@1b93dc9 (will post the captured log here on the next Mac reproduction).
Workaround: as noted upstream, the JSONL is intact; new session resumes the conversation via
--resume <uuid>if you can pull the session ID. The UI's "archived" pointer is the broken part.Happy to share a session UUID privately with Anthropic engineering for server-side correlation.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
- locked as resolved and limited conversation to collaborators
on Aug 15, 2026
What happened
An active Claude Code Desktop session auto-archives itself within seconds of the app losing window focus (e.g., alt-tab to a browser to look at a URL, return after ~30 s, find the session marked "This session is archived, to restart it click unarchive"). Has occurred 2+ times in the same continuous work session today.
The session was unambiguously not idle — it was mid-conversation with the assistant actively working on a multi-file feature.
Repro steps
Expected: session is exactly where I left it.
Actual: session pane shows "This session is archived, to restart it, click unarchive."
Diagnostic info
Stop/SessionStart/ archive hooks in usersettings.json, nosettings.local.json, nokeybindings.json, no scheduled tasks. No mechanism in the user's local config callsarchive_session.Related
Possibly the same root cause as #24534 ("Archived Code sessions not visible on Windows"), but the trigger here is much more specific — focus loss within seconds, not "vanished overnight."
Workaround
Manually click "Unarchive." Conversation state is preserved (the JSONL on disk is intact); only the UI pointer is broken.