[Feature]: Separate toggle for merged/closed-PR auto-settle (enables fully manual settling) #4982

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

I want threads in the sidebar to settle only when I settle them manually, and never automatically.

The existing "Auto-settle inactive threads" toggle in Beta settings already lets me turn off the inactivity-based auto-settle (it sets sidebarAutoSettleAfterDays to null). But there is a second, separate trigger I cannot turn off: a thread whose PR is merged or closed always settles immediately, regardless of that toggle. The settings panel even states this: "Threads on merged or closed PRs always settle."

For my workflow this is the wrong default. After a PR merges I often still want the thread front-and-center in the active list — to do follow-up work, verify the deploy, cherry-pick, or start a related change on the same branch — and having it disappear to the settled shelf the moment the PR merges means I lose track of it. Today the only escape hatch is per-thread — unsettling each thread after the fact, which I have to redo every time.

Proposed solution

Expose the two auto-settle triggers as two independent toggles in the Beta settings panel:

1. Auto-settle inactive threads — the existing inactivity-timeout toggle, unchanged.
2. Auto-settle threads on merged/closed PRs — a new toggle for the merged/closed-PR trigger, on by default so current behavior is preserved.

With both toggles off, threads never auto-settle and settling becomes fully manual.

The relevant logic is the merged/closed short-circuit in packages/client-runtime/src/state/threadSettled.ts (it returns settled for changeRequestState === "merged" | "closed" before the autoSettleAfterDays === null check), the setting schema sidebarAutoSettleAfterDays in packages/contracts/src/settings.ts, and the UI in apps/web/src/components/settings/BetaSettingsPanel.tsx. Manual thread.settle / thread.unsettle should keep working exactly as they do now (unsettling already pins a thread active until real activity via settledOverride === "active").

Why this matters

People who treat the sidebar as a live worklist want deterministic control over what leaves it. Auto-settling on merge is a good default for many, but for follow-up-heavy workflows it silently hides threads that are still relevant. A dedicated toggle for the merged/closed-PR trigger makes the behavior predictable and removes the need to repeatedly pin/unsettle individual threads.

Smallest useful scope

Add the single new "Auto-settle threads on merged/closed PRs" toggle (default on) that gates the merged/closed short-circuit. Combined with the existing inactivity toggle, turning both off makes settling fully manual.

Alternatives considered

• Manually unsettling each thread — works, but must be repeated for every thread and is reactive (the thread already jumped to settled).
• Turning off only the inactivity timeout (current behavior) — does not help, because merged/closed PRs still settle unconditionally.
• Related but different: [Feature]: Undo Settling a Thread #4706 (undo settling) and [Bug]: Threads are getting auto-settled minutes after completion #4811 (closed bug about unexpected time-based auto-settling, which also floated a manual-only mode + a keybind to toggle settled state).

Risks or tradeoffs

• Threads never leaving the active list on their own could grow the list for users who forget to settle — this is opt-in, so it only affects those who choose it.
• Need to make sure the merged/closed PR badge/state still renders on threads that stay active (settled state and PR state are already tracked separately, so this should be fine).

Examples or references

• Settings copy today: "Threads with no activity for this long settle automatically. Threads on merged or closed PRs always settle."
• Related issues: [Feature]: Undo Settling a Thread #4706, [Bug]: Threads are getting auto-settled minutes after completion #4811.

Contribution

• I would be open to helping implement this.