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

[Jardo-51]

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.

[nemesiscodex]

👍 this will be appreciated. If I want to work on main/master branch it always auto settles (They have merge down PRs)

My current workaround now is to always create a new branch, either by using the worktree feature or manually.

[El-Magico777]

Same issue here. I often use one thread as orchestrator thread, mostly it does not make its own pr's but sometimes just a small quick fix pr: and then the auto settling begins :(.

[jake-landersweb]

Me as well. This default behavior is frustrating, I use development as my base, but for a prod release I merge into main. Now t3code is stuck thinking that development branch is forever merged and always auto-settles.

[HemalR]

My current workaround until a fix is to open a standing draft PR so that threads stop auto-closing. It's a bit dirty and clutters the UI but better than losing threads to auto-settling.

[genesis-gh-agorshkov]

+1 I have Fable as PM and it runs a long-running project with many sub-agents and many PRs, that master thread should not settle until I do so manually even though at any given moment it might be in a state where all PRs have been merged.

My current workaround is to pin that thread.