Repository navigation
[Feature]: Auto Settle, hide a running thread and settle it silently when it's done #13630
Description
Activity
Triage: #13630
Verdict: Accept
Type: Feature request
Duplicate: No
Already implemented: No
Confidence: High
Suggested labels:enhancement,accepted
Scope: Medium. One one-shot per-thread intent, sidebar placement on web, desktop, and mobile, and completion-notification suppression. It must not reusethread.settlewhile the session is running.What was asked
A way to say "finish this and put it away" on one thread, including while the agent is still running:
- the thread leaves the active sidebar immediately and the agent keeps working
- when the work finishes it settles on its own, with no notification and without returning to the active list
- it stays findable with the other settled threads
- the name and control are flexible (
/auto-settlewas only an example)
Same request as Ideas discussion #13070, opened as an issue by the same author so it can be tracked. This issue is the tracker.
What the code does today
Settle means "done" and it refuses in-flight work.
thread.settleandthread.auto-settleinapps/server/src/orchestration/decider.tsreturnOrchestrationThreadSettleBlockedError("This thread still needs attention. Resolve or interrupt it first, then try again.") when the session isstartingorrunning, when an approval or a native question is open, or while a user message is still waiting to be adopted. The thread menu still offers Settle thread on a running thread. Only Archive thread is disabled whileisRunningis true (apps/web/src/components/threadActionMenu.logic.ts), so the click fails on the server.A real settle also stops the provider.
ProviderCommandReactorhandlesthread.settledby dispatchingthread.session.stopwithonlyIfSettled: true(apps/server/src/orchestration/Layers/ProviderCommandReactor.ts). Emittingthread.settledimmediately would kill the agent this request wants to leave running.Activity also undoes a settle. On
thread.session.set, a session moving tostartingorrunningemitsthread.unsettledwith reasonactivitywheneversettledOverrideis set. The comment in the decider says real activity resets any override. An approval or user-input request does the same. Forcing the settled flag early would hide the row for one status write and then pop it back.Automatic settlement does not cover this either.
isAutoSettlementCandidateinapps/server/src/orchestration/ThreadSettlementPolicy.tsskips running sessions, pending hands, queued turn starts, andbackgroundLiveness. It only fires after days of inactivity or a merged or closed pull request. The Auto-settle behavior submenu (autoSettleDisabledAt, shipped in #11846) is the opposite switch: Disabled keeps that thread out of those rules. Manual settle, snooze, and archive still work while it is disabled.Snooze is the closest hide-without-stopping action. A running session can be snoozed, and a session start does not clear snooze. Completion puts it back.
threadRaisedHandWhileSnoozedtreats a turn that completed aftersnoozedAtas a raised hand,effectiveSnoozedstops hiding the row, and it returns to the inbox. Notifications still fire.ThreadNotificationCoordinatorskips only archived threads, andresolveSidebarThreadStatusdoes not look at settled or snoozed. Mobile push follows agent awareness, andprojectThreadAwarenesspublishescompletedwith no settle check.Not a duplicate
- Auto Settle: hide a running thread and settle silently when done #13070 is this request, still open as a discussion. No separate issue.
- feat(threads): add per-thread auto-settle switch #11846 (merged) is the per-thread opt-out that keeps a thread active. The author already called that out.
- [Feature]: Opt-in setting so agents can settle their own thread #9942 (discussion) is an opt-in MCP tool so the agent can settle its own thread after the turn is idle. It does not hide the row up front and does not suppress the completion notification. The decider still rejects an in-turn settle, which that proposal works around by queueing. Complementary, not the same control.
- fix(threads): settle keep-active threads when PR merges #13615 (open) settles a keep-active thread when its pull request merges. Different trigger.
- feat(threads): add Pause session to park provider sessions and save RAM #12172 (open) adds Pause session, which stops the provider to save memory. This request needs the provider to keep running.
No open issue or PR arms a running thread to hide now and settle silently when idle.
Implementation notes
Do not relax
thread.settleto succeed while the session is running. That command's event stops the provider.Add a one-shot intent, separate from
settledOverrideand fromautoSettleDisabledAt. Something like "settle when idle", set from the existing Settle action when the thread is running and not blocked. Idle Settle stays the command it is today.While the intent is armed:
- File the row with the settled threads on web, desktop, and mobile, and leave the active list. Do not emit
thread.settledyet, and do not stop the session. Navigate away if this was the open thread, the same as settle and snooze already do. - A
startingorrunningsession from the in-flight turn must not clear the intent. That is the trap in thethread.session.setunsettle path. - A new user message, Un-settle, or a drag back to active cancels the intent and returns the row to active without stopping the session.
- An approval, a user-input request, or a session error cancels the intent, puts the row back in active, and still notifies. Hiding a blocked agent is the case snooze already refuses.
- When the thread matches the idle checks in
isAutoSettlementCandidate(session notstartingorrunning, no pending hand, no queued turn, nobackgroundLiveness), dispatch the normalthread.settle. The row is already in the settled shelf, so completion does not move it. The existing settle path then stops the idle session. - Skip the completion sound, in-app toast, desktop notification, and agent-awareness
completedpublish for that success. The flag has to be on the shell before the turn completes, because the web coordinator keys offlatestTurn.completedAt, notsettledOverride.
Keep it one-shot. After the real settle, the next user message behaves like any other settled thread. Do not add a second Auto-settle menu entry. That name is already the opt-out submenu. A composer slash command is the wrong surface.
/plan,/default, and/modelare composer commands, not thread lifecycle.A watch loop that never ends never reaches
thread.settled, so the session stays up. The row still stays out of active because of the intent. Same idle rule as automatic settlement. Do not stop the session to force the shelf.Risks
The intent and
thread.settledhave to stay distinct. Collapsing them reintroduces the session stop and the activity unsettle.Notification suppression has to be limited to the successful completion of an armed thread. A failure or a question that stays hidden is a lost thread.
Un-settle before the turn finishes must only cancel the intent. It must not stop the provider.
Reacted by Paweł Kica and Samuel ChrenoI opened #14495 for this, following the implementation notes above.
This was a real day-to-day friction point for me. I kept wanting to put a thread away while the agent wrapped up its last step. The only choices were to leave it cluttering the active list or interrupt it, and it kept pulling me out of what I was doing. So I built it.
How it maps to the notes:
thread.settleis unchanged and still refuses a running session. On a working thread (running, queued turn, or livebackgroundLiveness), the server arms a separate one-shot intent (settleWhenIdleAt) instead.- The row files with the settled threads right away (shown as "Working") on web, desktop, and mobile. The session keeps running.
- The existing
ThreadSettlementReactorsettles it once the thread is idle, throughthread.auto-settle, so its snapshot and background-liveness guards apply. Watch loops and subagents are never stopped. - A new message, Un-settle, pin, or drag back cancels it without stopping the session. An approval, a question, or a session error cancels it and still notifies.
- The quiet finish skips the toast, sound, desktop notification, and agent-awareness
completedpublish.
Before/after screenshots and a short video are in the PR. Happy to shrink or change anything, and no worries if you'd rather build it yourselves.
- added a commit that references this issue
on Oct 3, 2026 Another case for this, coming from the agent instead of the sidebar.
I often end a prompt with "when you're done with X and Y, settle this thread". As its last step the agent calls
t3_thread_organizewithaction: "settle"on its own thread, and that always fails: its own turn is still running at that point. The decider rejects it (Orchestrator.ts:2514, "has active or blocked work and cannot be settled"), which is right forthread.settleas it works today.The one-shot "settle once idle" intent from the triage would cover this as well, if the MCP
settleaction armed that intent when the caller's run is still active instead of failing. An agent settling its own thread is always settling a running thread, so without that it can never do it.#14495 was closed with the V2 merge. Is anyone rebuilding this on V2?
Thanks for flagging this! I’m working on rebuilding this for V2, and I’ll take this case into account too—an agent requesting to settle its own thread once its turn finishes.
+1 for this. i run daily automations that can have a meaningful result only every week or so. i'd love the agent to have a tool to settle itself at the end, when there is no meaningful output. having to manually settle every run defeats the point of notifying me only when something matters
honestly after v2 this is the only thing holding me back from fully switching away from the codex desktop app -- silent automations
- added a commit that references this issue
on Oct 6, 2026 - added a commit that references this issue
on Oct 6, 2026 Same case here, with a T3 scheduled task (
schedule_task,bindToCurrentThread: true) that runs hourly in one thread. Almost every run finds nothing and posts one line, but each run puts the thread back in the active list.What I tried from inside the run:
t3_thread_organizesnooze: accepted, but the run's own completion clears it again (same mechanism as [Feature]: Let me hide agent-to-agent threads: a snooze that holds until its time, whatever activity happens #14625).t3_thread_organizesettle: refused because the run is still active. The MCP only returns "The operation could not be completed." ([Bug]: MCP thread tools replace the orchestrator's rejection reason with "The operation could not be completed." #15586).
Arming "settle once idle" when the caller's own run is still active would cover this exactly: a quiet run settles its thread on the way out, and a run with something to report just doesn't. A scheduled run that then starts in a settled thread should stay settled unless the agent unsettles it or marks it unread.
Reacted by Luke Floden
I often give an agent a task with a clear outcome, like saving a doc to my desktop or running a long job, and I don't really need to read its final reply. What I'd love is to clear that thread out of my sidebar right away, let it keep working, and never have to come back and settle it by hand.
Something like an Auto Settle action, maybe
/auto-settle:Basically a way to say "finish this and put it away" upfront. The name and exact interaction are totally flexible.
I posted this in Ideas first (#13070) and I'm opening it as an issue so it's easier to track. By the way, #11846 (the per-thread auto-settle switch) goes the other way and keeps a thread active, and #9942 is about agents settling their own threads, so neither covers this.