›_ Claude Code Issues
Claude Code Issues / #57586

Desktop app: chats moved from Archived back to Active are auto-archived again after ~1 second

Status Fixed / completed
Reported on v2.1.128
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 9 comments · opened May 9, 2026 · closed May 19, 2026

Summary

On the Claude Code desktop app (macOS), chats that I move from Archived back to Active are silently re-archived after roughly one second, without any user action. This also explains why two chats I had pinned to the sidebar's Pinned section disappeared on their own — they got auto-archived, which removed them from the Pinned list.

Steps to reproduce

  1. Open a project (in my case cinetica-pro).
  2. Open the Archived view and find a chat there.
  3. Move the chat back to Active.
  4. Wait ~1 second — the chat reappears under Archived on its own.

Same behaviour observed on two different chats ("Generali", "Ordini e fornitori"). They had previously been pinned in the sidebar; both were silently moved to Archived and now refuse to stay in Active.

Expected

A chat moved out of Archived stays in Active until the user explicitly archives it again.

Actual

The chat snaps back to Archived after about one second, every time. Pinned state is also lost in the process (the chat is no longer in the Pinned section after the auto-archive, and re-activating it does not restore the pin either).

Environment

  • Claude Code desktop app: 2.1.128
  • Claude Code CLI (parallel install): 2.1.39
  • macOS: 26.4.1 (build 25E253)
  • Single-Mac, no cross-device sync involved
  • App restart does not change the behaviour

Notes

  • The chats themselves are intact (messages preserved); the issue is purely the archive flag flipping back automatically.
  • Inspected ~/Library/Application Support/Claude/Local Storage/leveldb/: pinnedOrder is currently [] while one chat is still rendered under Pinned, suggesting the sidebar's pin order array can also drift out of sync with per-session state — but the primary user-visible issue is the auto re-archival loop.

View original on GitHub ↗

9 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/41378
  2. https://github.com/anthropics/claude-code/issues/24534
  3. https://github.com/anthropics/claude-code/issues/57194

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

HoopyFrood42 · 3 months ago

I'm also having this issue on MacOs – same exact situation as OP. Other notes:

  • I was nearing the end of my token limit
  • I compacted during the session
  • I renamed the chat directly before the session archived itself
  • I did not take any kind of archive action
  • Another bug occurred during the same session where the PR widget would not go away, even after closing and then removing the PR and after restarting the app and then updating to Claude 1.6608.2 (ebf1a1) 2026-05-08T23:17:27.000Z and restarting
damschmitty · 3 months ago

Same bug on Windows, with a more specific trigger from the logs.

Environment

  • Claude Desktop: 1.5354.0 (Windows Store install)
  • Claude Code CLI: 2.1.128
  • OS: Windows 11

Trigger we identified

The Desktop main log shows the re-archiver is the [AutoArchiveEngine], and at least one of its triggers is PR merged for the session's associated GitHub PR.

Today's session (local_dca9ea02-…) was archived, manually unarchived, and re-archived twice within minutes — exactly the OP's symptom:

17:03:37  [AutoArchiveEngine] Archiving local_dca9ea02-… (PR merged)
22:22:28  LocalSessions.unarchive: sessionId=local_dca9ea02-…   ← user
22:22:28  Unarchived session local_dca9ea02-…
22:28:36  [AutoArchiveEngine] Archiving local_dca9ea02-… (PR merged)   ← engine again
22:34:48  LocalSessions.unarchive: sessionId=local_dca9ea02-…   ← user
22:34:48  Unarchived session local_dca9ea02-…

Same pattern on prior days for sessions whose PRs had merged — engine re-fires every 10–20 min. From ~/AppData/Roaming/Claude/logs/main1.log:

2026-05-05 12:09:55 [info] [AutoArchiveEngine] Archiving local_b01fd310-… (PR merged)
2026-05-05 12:19:55 [info] [AutoArchiveEngine] Archiving local_b01fd310-… (PR merged)
2026-05-05 12:39:55 [info] [AutoArchiveEngine] Archiving local_b01fd310-… (PR merged)

Likely root cause

The engine's "should I archive?" predicate is purely state-based (PR is merged) with no awareness that the user has already manually unarchived this session. So every time the engine ticks (looks like ~6–20 min cadence on the PR-merged path; OP reports ~1s on macOS, possibly a different code path), it sees the merged PR and re-archives.

Suggested fix

Persist the user's manual-unarchive intent. Either:

  • Skip auto-archive once a session has been manually unarchived (per session, sticky), OR
  • Only auto-archive on the transition to PR-merged, not on every tick while in the merged state.

Workaround for affected users

After merging a PR, finish work in a new session — the existing one will keep getting re-archived no matter how often you unarchive it.

viviane1016 · 3 months ago

Seeing the same behaviour on macOS during an active long-running session (not after moving from Archived — during live use).

Pattern:

  1. Active session running normally (long bees workflow session — plan/spec/dispatch/merge cycles over several hours)
  2. Session auto-archives itself mid-conversation with "This session has been archived, unarchive to continue"
  3. Unarchive to resume
  4. Session auto-archives itself again ~1 second later
  5. Unarchive again — stays active this time

So the re-archive-on-unarchive loop you describe also manifests here, just with the initial archive trigger being something other than manual re-activation. The session was continuously active (no inactivity gap visible in the transcript) when the first archive fired.

Environment:

  • macOS 25.4.0
  • Claude Code desktop app
HoopyFrood42 · 3 months ago

@claude this was closed without resolution despite consistent reporting activity and having no similarity to the suggested dupes. Maybe you could use some HITL...

viviane1016 · 3 months ago

I've not noticed this in my most recent session - hopefully resolved, could do with some improved comms :)

nagelm · 3 months ago

Still happening in a new session

viviane1016 · 3 months ago

yes also still seeing today.

github-actions[bot] · 1 month ago

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.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →