Before submitting
Area
apps/web
Problem or use case
Some threads are long-lived by nature — a release thread, an ops/monitoring thread, a thread with background watchers waiting on external events. For those, every automatic settle is noise: I have to un-settle again and again, and a settled thread visually reads as "done" when it very much isn't.
Settling has several independent triggers, and today I can opt out of none of them per-thread. From packages/client-runtime/src/state/threadSettled.ts (effectiveSettled): a merged/closed PR settles immediately; inactivity past autoSettleAfterDays settles; and per #5514 a thread can pick up a PR association it never asked for, which then drives its settle state.
The model already has the right primitive: settledOverride: "active", described in that file as "the explicit keep-active pin". But it is transient — the same comment notes it only "suppresses auto-settle until real activity clears it server-side". So un-settling a thread buys me exactly one turn before it settles again (this is likely the mechanism behind #5476).
Proposal
A durable per-thread pin (context menu on the sidebar row, or thread settings) — e.g. "Never settle" / "Keep active". A pinned thread:
- is never auto-settled by any trigger (inactivity, merged/closed PR, PR association)
- is not cleared by activity — only the user removes the pin
- never shows settle banners or prompts, but can still be settled manually if I explicitly choose to
Related
#4982 asks for a global toggle on the merged/closed-PR rule; this is the per-thread complement that also covers the inactivity trigger. See also #5476 and #5514.
Before submitting
Area
apps/web
Problem or use case
Some threads are long-lived by nature — a release thread, an ops/monitoring thread, a thread with background watchers waiting on external events. For those, every automatic settle is noise: I have to un-settle again and again, and a settled thread visually reads as "done" when it very much isn't.
Settling has several independent triggers, and today I can opt out of none of them per-thread. From
packages/client-runtime/src/state/threadSettled.ts(effectiveSettled): a merged/closed PR settles immediately; inactivity pastautoSettleAfterDayssettles; and per #5514 a thread can pick up a PR association it never asked for, which then drives its settle state.The model already has the right primitive:
settledOverride: "active", described in that file as "the explicit keep-active pin". But it is transient — the same comment notes it only "suppresses auto-settle until real activity clears it server-side". So un-settling a thread buys me exactly one turn before it settles again (this is likely the mechanism behind #5476).Proposal
A durable per-thread pin (context menu on the sidebar row, or thread settings) — e.g. "Never settle" / "Keep active". A pinned thread:
Related
#4982 asks for a global toggle on the merged/closed-PR rule; this is the per-thread complement that also covers the inactivity trigger. See also #5476 and #5514.