[Feature]: Opt-in setting so agents can settle their own thread

[Sma-Das]

Before submitting

• I searched existing issues and Ideas discussions. Closest neighbors are user-driven settle actions (Add Settle + new thread to thread actions #8847, Settle command or hotkey (keyboard only) #7509), auto-settle policy ([Feature]: Separate toggle for merged/closed-PR auto-settle (enables fully manual settling) #6833 / Allow disabling auto-settle when a thread's PR is merged #7004), and a user-clicked handoff that settles the old thread (Continue a structured handoff in a fresh thread #8754). None of those let the agent settle itself.
• This is a concrete problem, not a vague idea.

Area

apps/server (provider-scoped t3-code MCP), plus Settings → General next to the existing settle rules.

Problem or use case

An agent cannot settle the thread it is running in. The provider-scoped t3-code MCP exposes the preview toolkit (preview_open, snapshot, click, and so on). There is no settle tool.

thread.settle is a control-plane command (thread menu or ⌘⇧S). The orchestration decider also rejects settle while the session is starting or running, so an in-turn agent could not close its own thread even if that RPC were exposed.

A finished thread therefore stays in Active until a human settles it.

Proposed behavior

Add an opt-in setting, default off, next to the existing settle rules in Settings → General. Something like Allow agents to settle their own thread.

When it is on, the provider-scoped t3-code MCP exposes one tool, scoped to the calling thread only, e.g. t3_thread_settle.

That tool should:

• settle only the thread that owns the MCP session, never an arbitrary thread id
• reuse the existing thread.settle command and the same blockers as auto-settle (pending questions, approvals, live background work)
• queue the settle until the current turn is idle, because settle is rejected while the session is running
• leave Un-settle human-only

When the setting is off, the tool is not advertised.

Why this matters

Settle already means the work is done and already stops the idle provider session. The missing piece is letting the agent say that about its own thread, under a switch the user controls. Auto-settle on inactivity or PR merge is a different signal. Those fire without the agent declaring done.

Smallest useful scope

One setting (default off). One MCP tool. Current thread only. Post-turn thread.settle. No archive, no delete, no settling other threads, no change to auto-settle policy.

Alternatives considered

• Manual settle from the menu / ⌘⇧S. Works, but the agent cannot mark its own finished work.
• Auto-settle after inactivity or on merged/closed PRs. Wrong trigger. A thread can be done with no PR, or still be active after a merge.
• Continue a structured handoff in a fresh thread #8754 (Continue in new thread). User click after a handoff marker. Complementary, not a substitute.

Risks or tradeoffs

Agents will sometimes call settle too early. That is why this is opt-in, own-thread-only, and blocked by pending work. A "settle when idle" path is required or the tool is a no-op at the end of a successful turn, which is the only moment it would be called.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

This landed in #17145: an agent can now settle its own thread through the t3-code MCP. While its turn is still running, the settle waits for the turn to end and then runs the normal thread.settle. A failed or interrupted turn, or a queued user message, leaves the thread active. Closing as resolved. If you still want the separate opt-in setting, please open a new idea.