[Feature]: Auto Settle, hide a running thread and settle it silently when it's done

[Pawel-Kica]

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:

• you turn it on for one thread, also while the agent is still running
• the thread leaves the active sidebar right away and the agent keeps going
• when the work finishes it settles on its own, with no notification and without popping back into the sidebar
• you can still find it with your other settled threads

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.

[juliusmarminge]

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 reuse thread.settle while 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-settle was 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.settle and thread.auto-settle in apps/server/src/orchestration/decider.ts return OrchestrationThreadSettleBlockedError ("This thread still needs attention. Resolve or interrupt it first, then try again.") when the session is starting or running, 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 while isRunning is true (apps/web/src/components/threadActionMenu.logic.ts), so the click fails on the server.

A real settle also stops the provider. ProviderCommandReactor handles thread.settled by dispatching thread.session.stop with onlyIfSettled: true (apps/server/src/orchestration/Layers/ProviderCommandReactor.ts). Emitting thread.settled immediately would kill the agent this request wants to leave running.

Activity also undoes a settle. On thread.session.set, a session moving to starting or running emits thread.unsettled with reason activity whenever settledOverride is 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. isAutoSettlementCandidate in apps/server/src/orchestration/ThreadSettlementPolicy.ts skips running sessions, pending hands, queued turn starts, and backgroundLiveness. 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. threadRaisedHandWhileSnoozed treats a turn that completed after snoozedAt as a raised hand, effectiveSnoozed stops hiding the row, and it returns to the inbox. Notifications still fire. ThreadNotificationCoordinator skips only archived threads, and resolveSidebarThreadStatus does not look at settled or snoozed. Mobile push follows agent awareness, and projectThreadAwareness publishes completed with 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.settle to succeed while the session is running. That command's event stops the provider.

Add a one-shot intent, separate from settledOverride and from autoSettleDisabledAt. 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.settled yet, and do not stop the session. Navigate away if this was the open thread, the same as settle and snooze already do.
• A starting or running session from the in-flight turn must not clear the intent. That is the trap in the thread.session.set unsettle 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 not starting or running, no pending hand, no queued turn, no backgroundLiveness), dispatch the normal thread.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 completed publish for that success. The flag has to be on the shell before the turn completes, because the web coordinator keys off latestTurn.completedAt, not settledOverride.

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 /model are 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.settled have 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.

[piotrnowakowski]

I 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.settle is unchanged and still refuses a running session. On a working thread (running, queued turn, or live backgroundLiveness), 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 ThreadSettlementReactor settles it once the thread is idle, through thread.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 completed publish.

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.

[angelospk]

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_organize with action: "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 for thread.settle as it works today.

The one-shot "settle once idle" intent from the triage would cover this as well, if the MCP settle action 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?

[piotrnowakowski]

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.

[samochreno]

+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

[TimPeterNL]

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_organize snooze: 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_organize settle: 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.

[josephv123]

+1, I hit this daily: I send a prompt I don't need to review and then have to remember to come back and settle it. A few thoughts on the shape, building on #18606:

1. Settle on a working thread arms "settle when done" instead of the "is still running. Stop it before settling." error. The thread files under Settled right away, settles quietly on success, and comes back to Active only if it asks a question, needs an approval, or fails, so a stalled agent never hides. This is what feat(threads): file working threads and settle quietly when idle #18606 does, and it covers every existing Settle entry point (menu, hover button, drag, keybinding, mobile swipe, t3_thread_organize).
2. "Send and settle" in the composer: a send variant (for example Mod+Shift+Enter, or an item on the send button) that sends the prompt and arms (1) in one step, so a fire-and-forget thread never appears in Active at all. Small once (1) exists.
3. A "When done" choice in the per-thread Auto-settle behavior menu (Enabled / Disabled / When done) that settles the thread after every turn that completes cleanly. This covers the scheduled-task threads mentioned above, which run often and rarely produce anything worth reading. Same exceptions as (1).

(1) seems like the right core; (2) and (3) are thin layers on the same intent.