Pinned sessions are silently auto-archived in the Windows desktop app; pinning does not prevent auto-archiving and there is no opt-out

Environment

• Platform: Windows 11, Claude Code desktop app
• Version: 2.1.220 (also occurred on earlier 2.1.x versions)
• Setup: several long-lived named sessions ("lanes"), each working in its own git worktree, kept open for days

Summary

Long-lived sessions are moved into Archived automatically, without any user action. Critically, a session
that has been pinned is still auto-archived, which contradicts the documented purpose of pinning. The user
located a missing session in the Archived list while it was still flagged as pinned.

There is no documented setting — in settings.json or in the app — to disable, delay, or configure
auto-archiving.

Steps to reproduce

1. Open the Claude Code desktop app on Windows.
2. Create or open a long-lived named session.
3. Pin the session.
4. Continue working across other applications and other sessions over a period of hours.
5. Observe that the session eventually disappears from the active list, and is found under Archived — while

still pinned.

Expected

A pinned session stays in the active list. Pinning exists precisely to keep a session available and should
exempt it from any automatic archiving.

Actual

The session is silently moved to Archived. The user never archived it. It recurs, and the pinned state does not
prevent it.

Specific evidence from this user

The strongest single data point: the session was found in a state of "archived but pinned." Whatever moves
sessions to Archived is not consulting the pinned flag. This directly contradicts what pinning is for, and is a
narrower and more reproducible symptom than the general "sessions disappear" reports below.

Impact

The user runs several long-lived lanes and relies on the session list to know which are active and which need
attention. Sessions vanishing without action means:

• Time lost hunting for a session believed to be gone.
• Reduced trust in the session list as a picture of what is running.
• Pinning, the one control offered for this, does not work.

No work is lost — the conversation, the code, and the git history are all intact, and un-archiving restores the
session. This is a workflow defect rather than a data-loss defect.

Related public issues

These describe the same or adjacent behaviour and may be duplicates or a common root cause:

• #57586 — chats moved from Archived back to Active are auto-archived again after about a second; **the

pinned state is lost in the process**. (Closest match to this report.)

• #57602 — active session auto-archives within seconds of the app losing window focus (Windows). Closed as

"not planned".

• #68972 — sessions auto-archived immediately after Claude sends a message (Windows desktop).
• #59449 — active session auto-archived roughly every five minutes during normal interaction.
• #60043 — long working sessions auto-archive mid-conversation, with no opt-out. Requests a

disableAutoArchive setting, which does not exist.

• #62428 — no user interface to restore or un-archive sessions in the desktop app.

What would resolve this

Either of the following would be sufficient:

1. Make pinning authoritative — a pinned session is never auto-archived under any trigger. This is the

minimum fix, since it makes the existing control do what it says.

1. Provide an opt-out setting — for example disableAutoArchive: true in settings.json, as requested in

#60043.

A documented explanation of what actually triggers auto-archiving would also help, since it is currently
undocumented and users cannot avoid a trigger they cannot see.

---

Related: #57586 (closed) describes the same pinned-state loss. Filing separately as that issue is closed; happy for this to be merged if preferred.