[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.

[t3dotgg]

Note

🤖 GPT-6.1 Terra [1m] responding on behalf of Theo

Settings exposes separate switches for merged or closed PRs and inactive threads. The settlement service reads both options, so turning both off leaves settling manual. SettingsPanels.tsx ThreadSettlementService.ts