Chat sessions auto-archived repeatedly without user action (v2.1.69)

Same behavior here (macOS, Claude Code desktop app), and I think I found the trigger.

Correlation observed: across my sessions, every one that has an associated PR shows isArchived: true if and only if that PR is MERGED. Sessions with no PR stay isArchived: false. In one active session today, after merging several PRs back-to-back over the course of the conversation, the session was repeatedly auto-archived while still in active, continuous use — I had to keep hitting "unarchive" to keep talking to it.

So it looks like archiving fires on PR merge/close, not on session idle/completion.

There is a setting that matches this exactly: Settings → Claude Code → "Auto-archive after PR merge or close". Worth checking whether it's on by default and firing even when the session that opened the PR is still the one you're actively chatting in — that's the actual bug, since the setting's own name implies it should be safe to leave on. Archiving a session the user is currently typing into (not merely "after the PR merged, later") is the part that breaks the workflow.

No hooks, no project/user .claude/settings.json config, and no explicit archive_session tool call caused this on my end — consistent with what's already noted in this issue.

Also seeing this on Windows 11 Pro (10.0.26200) with Claude Code 2.1.246 — so it is not macOS-specific and it still reproduces 5 versions later than the original report.

However, our data does not support the PR MERGED ⇔ isArchived correlation from the comment above. Posting it because a counter-example may narrow the cause.

We run 6 long-lived sessions in one repo. Snapshot from list_sessions(include_archived: true), with session titles and PR numbers redacted:

| session | prState | isArchived |
|---|---|---|
| A | MERGED | false |
| B | MERGED | false |
| C | MERGED | false |
| D | MERGED | false |
| E | CLOSED | false |
| F | (no PR) | true |
| G | (no PR) | true |
| H | (no PR) | true |
| I | MERGED | true |
| J | (no PR) | true |
| K | (no PR) | true |
| L | (no PR) | true |
| M | (no PR) | true |

Two things break the correlation in both directions:

• 4 sessions with prState: MERGED are NOT archived. If merging a PR triggered the archive, these should have been archived.
• 7 of the 8 archived sessions have no associated PR at all. Only one archived session has a merged PR.

So in this environment the archived set is almost the complement of what the PR hypothesis predicts.

What we can and cannot say

• We confirmed the archiving was not initiated by our own tooling: we grepped every session transcript for archive_session calls and found none corresponding to these sessions. No archive-related hooks or settings exist in ~/.claude/settings.json or the project .claude configs.
• Three sessions were archived on a single day (2026-08-31) without user action, during a period of heavy parallel work across all sessions.
• We cannot give a reproduction. lastActivityAt is the last activity, not the archive time, so we cannot correlate the archive events with anything that happened around them. If the API exposed an archivedAt timestamp, this would be far easier to diagnose — that alone would let affected users correlate the event with merges, idle timeouts, session counts, or app restarts.

Impact for multi-session users

We coordinate several sessions that message each other. When one is archived mid-flight, the work in it stalls silently — the other sessions keep sending to a session that no longer responds, and it is not obvious that archiving is the cause. A user-visible notification on auto-archive (or the setting to disable it requested in the original post) would remove most of the damage even if the root cause takes longer to find.

Third occurrence, and this time with direct evidence that the session did not call the archive tool.

Environment: Windows 11 Pro (10.0.26200), Claude Code desktop app, bypass permissions mode (so no confirmation prompt is shown to the user).

Occurrences:

• 2026-09-01: two sessions auto-archived (reported above)
• 2026-09-02 ~11:20 JST: a third session auto-archived while idle, in a different session than the previous two

What makes this one useful: for the 2026-09-02 case we searched the affected session's own transcript rather than relying on the model's recollection. archive_session appears 22 times in the transcript, and zero of them are actual tool invocations. The breakdown:

• tool-availability notices listing the tool name (2)
• a reminder injected from the session's own memory files telling it not to archive anything
• the investigation itself discussing the term

So the session never called it. The archive happened without any tool call from the session, and without a user action.

Why bypass mode matters here: in that mode no confirmation prompt reaches the user, so an archive is immediate and silent. For a fleet of long-running sessions this means work-in-progress state can disappear with no signal at all — we lost visibility of a running lane and only noticed because the user happened to look at the session list.

Still reproducing across versions and across two OSes.