Long working sessions auto-archive mid-conversation; no opt-out

Status Open

Maintainer reply None cached

Activity 6 comments · opened May 17, 2026

Symptom

In an active Claude Code session — specifically the chat UI (claude.ai/code in a browser, or possibly the desktop app — see env note below) — the input field gets replaced with a notice that reads "this conversation has been archived" and an "Unarchive to continue chat" button. This happens automatically without any user action, apparently after some inactivity threshold.

The conversation is recoverable via the Unarchive button (so no data is lost), but for long working sessions that include multi-step plans, sub-agents in progress, MCP tool state, and verification cycles, having the input field disappear mid-flow is disruptive. The "Unarchive" prompt also makes it look like the model has stopped responding, when really the user just needs to click through.

What I tried (and what didn't fix it)

Setting cleanupPeriodDays: 999999 in %USERPROFILE%\.claude\settings.json does not prevent this — that setting controls local transcript file cleanup at startup, not the in-chat archive behavior.

What I'm looking for

Either:

A user-facing setting (e.g. disableAutoArchive: true in settings.json, or a per-conversation "pin" / "keep active" toggle in the UI), OR
Documentation explaining the threshold so we can plan around it

Why this matters for working sessions

For typical short Q&A chats the auto-archive is probably fine — it keeps the active list manageable. But Claude Code working sessions routinely run 1–4 hours and include:

Background agents that I'm waiting on
Multi-step plans where I step away to take an action (apply a migration, click through a dashboard, run a manual test) and come back
MCP tool state I don't want to interrupt

When the chat archives during that gap, it breaks the flow and forces an extra click that can fire on top of an in-progress response.

Environment

Platform: Windows 11
Claude Code: confirmed running but couldn't determine version via claude --version, npm globals, registry, or %LOCALAPPDATA%\Programs — suggests browser-based use of claude.ai/code (or a non-standard install path)
Symptom occurs across multiple long-running sessions

Workaround for now

Click "Unarchive" whenever it appears. That works but isn't viable for sessions where the user wants to leave Claude Code running unattended (e.g., during a long background agent or a multi-hour build).

---

Thanks for considering. Happy to provide more detail or test a proposed fix.

View original on GitHub ↗

6 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

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

kcarriedo · 3 months ago

The dup-bot is roughly right — #59449, #59235, and #59451 are all looking at this same family of behavior — and #59449 is the most active living thread if you want to add the Windows-11 + multi-hour-working-session signal there before this one auto-closes.

Two things in your report look genuinely useful for the maintainer triage that the 3 dups don't surface as crisply:

The cleanupPeriodDays: 999999 red-herring. That's the first setting most users will try (it sounds adjacent and it's documented). Confirming on the issue that it does nothing for in-chat archive is a useful disambiguation — the chat-archive timer is a separate subsystem from local transcript cleanup, and treating them as the same setting is what most affected users will do first.
The "looks like the model stopped responding" framing. Most of the existing dups frame this as a UI annoyance. The actual operator-impact is that it's indistinguishable from a hung session at a glance — which means the human will react by killing/restarting before clicking Unarchive, and that is the loss-of-state event, not the archive itself.

For multi-hour working sessions while this is being triaged, three operator workarounds that have held up for us:

Heartbeat tick from the agent side. If you're running anything that can spawn its own tool call (sub-agent, MCP server, background process), have it issue a no-op tool call every 2–3 minutes — a Bash(echo .) or a Read on a sentinel file. That keeps the conversation classified as active and prevents the archive trigger entirely in our testing.
Don't run long-form work in the chat tab. If the work tolerates it, move the long-running portion to claude -p (print mode) or a claude --resume <session-id> invocation from a terminal — the archive timer is a chat-UI artifact, not a session-state artifact. The session ID survives; the archive flag is what flips, and --resume ignores it.
External cron heartbeat against the session. If you're orchestrating from outside Claude Code (cron job, scheduler, supervisor), poll the session file under ~/.claude/projects/<project-hash>/ for mtime changes and emit a tool-input touch from your supervisor when it stalls — same effect as (1) but driven from the orchestrator, not from inside the agent.

None of these are a substitute for the per-conversation pin / disableAutoArchive you asked for. They're load-bearing for keeping a multi-hour working session alive against the current behavior.

gwickman · 2 months ago

The workarounds don't reliably work on claude code (desktop) sessions we need a way to disable this stupidity.

ayanami770 · 2 months ago

Also running into this on the desktop app.

I run multi-hour Claude Code desktop sessions (long CI/build loops + multi-step refactors), and the conversation gets auto-archived mid-task while I'm actively working in it — I then have to Unarchive to continue, which breaks flow and is easy to miss.

Workarounds that don't help, for the record:

cleanupPeriodDays in ~/.claude/settings.json — no effect; it only governs local transcript deletion, not the archive behavior.
No documented settings.json key or UI toggle to opt out.

Request: a user-facing opt-out — e.g. a disableAutoArchive (or autoArchive: false, or a configurable idle threshold) key in settings.json — so long-running sessions aren't archived out from under an active workflow.

Thanks!

gwickman · 2 months ago

This issue makes the desktop app useless for some of us. The only viable workaround is to run from a terminal so please fix this I otherwise like the desktop app but now never use it.

Alvarado1-ai · 1 month ago

Also hitting this on the desktop app — Claude.app 1.24012.1, Claude Code 2.1.214, macOS 26.4.1.

Active sessions with no linked PR get archived daily while work is in progress. From local session state (~/Library/Application Support/Claude/claude-code-sessions), most archived sessions are not PR-linked — e.g. Jul 22: 29 archived (only 3 PR-linked), Jul 23: 11 (2 PR-linked) — so this is separate from the "Auto-archive after PR merge or close" preference and has no visible opt-out.

Two observations from digging into local state that may help triage:

Session-state JSON carries an autoArchiveExempt flag (set after a manual unarchive), but it doesn't appear to reliably prevent re-archiving — one restored session was re-archived within ~30 minutes with autoArchiveExempt: true on disk (the PR-close preference was still enabled in the running app at that point, so that instance may be the PR path — but the flag not protecting a just-restored session seems wrong either way).
There's no local workaround: the running app treats claude_desktop_config.json and the session-state files as write-through mirrors — external edits are ignored and overwritten.

An explicit "never auto-archive" setting — or honoring autoArchiveExempt / activity recency for running sessions — would resolve this. Multi-session workflows lose active sessions to the Archived list dozens of times a week.