claude-code - 💡(How to fix) Fix Auto-archive on PR merge / branch delete — clarify autoArchiveSessions semantics or add dedicated opt-out

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

When I merge a GitHub PR (with "Automatically delete head branches" enabled on the repo, so the source branch is deleted right after merge), my Claude Code session that was working on that branch gets auto-archived. There appears to be no documented opt-out for this specific trigger.

Root Cause

When I merge a GitHub PR (with "Automatically delete head branches" enabled on the repo, so the source branch is deleted right after merge), my Claude Code session that was working on that branch gets auto-archived. There appears to be no documented opt-out for this specific trigger.

RAW_BUFFERClick to expand / collapse

Summary

When I merge a GitHub PR (with "Automatically delete head branches" enabled on the repo, so the source branch is deleted right after merge), my Claude Code session that was working on that branch gets auto-archived. There appears to be no documented opt-out for this specific trigger.

Steps to reproduce

  1. Start a Claude Code session in a repo where "Automatically delete head branches" is enabled on the GitHub side.
  2. Create a feature branch, do work, push, open a PR via gh pr create.
  3. Merge the PR via the GitHub UI (or gh pr merge). The source branch is deleted automatically by GitHub.
  4. Observe: the active Claude Code session is archived (disappears from the active sessions list, must be retrieved via the archived panel / list_sessions).

Expected behavior

Either:

  • Archival is gated by an explicit, documented setting that I can opt out of, or
  • The session stays active until I explicitly end it (since I may still want to follow up on the same task in the same context — e.g. run the cleanup SQL after the release deploys).

Questions for maintainers

  1. Is the trigger the branch deletion (so disabling "delete head branches" on GitHub would prevent it), or the PR merge event itself (so the session would archive regardless of branch retention)?
  2. Does autoArchiveSessions: false (referenced in #60074 for worktree sessions) also cover the merge/branch-delete trigger? The setting is not in any documented settings list I can find.
  3. If the trigger is intentional (heuristic for "work is done"), can we get a dedicated opt-out — e.g. autoArchiveOnBranchDelete: false — independent of the broader autoArchiveSessions flag, since the two cases (idle/explicit close vs. branch deletion) have very different intent?

Related

  • #60074 — autoArchiveSessions: false ignored for worktree sessions
  • #61101 — sessions auto-archive with no UI to resume
  • #60043 — long working sessions auto-archive mid-conversation; no opt-out
  • #59451, #58446 — auto-archive every 30–90 min (cwd-bucket specific)

Environment

  • OS: macOS (Darwin 25.4.0)
  • Claude Code: CLI variant (with ccd_session_mgmt MCP tools — appears to be Desktop-managed)
  • Shell: zsh
  • No autoArchiveSessions setting present in my ~/.claude/settings.json (so any default behavior applies)

Impact

Common workflow loss: a release PR is merged, then I want to instruct Claude to run a follow-up step (production SQL cleanup, post-deploy verification, release-notes drafting). The session being archived right at that moment breaks the continuation, requiring explicit retrieval from the archive panel. Mild friction per occurrence, but it happens after every release.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Either:

  • Archival is gated by an explicit, documented setting that I can opt out of, or
  • The session stays active until I explicitly end it (since I may still want to follow up on the same task in the same context — e.g. run the cleanup SQL after the release deploys).

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING