Let agents turn a thread's auto-settle off through the t3-code MCP

[emiliarepo]

Note

[claude-opus-5-5] Written by Claude Opus 5.5 on behalf of Emilia.

Before submitting

• I searched existing issues and Ideas discussions. Closest: [Bug]: An agent-orchestrated thread re-settles after every turn once its linked PRs merged, killing its background commands, and MCP has no way to opt it out #19263 asked for this as one of three fixes and was closed as a duplicate of [Bug]: Thread auto-settles while the agent is still waiting on a background command #17625, which covers background commands rather than the MCP gap. Auto-settle on merge: give the user time to read the agent's final reply when the agent merged the PR itself #14930 holds settlement for a grace period after an agent merges. Expose pinned state in orchestrator MCP thread tools (t3_thread_list / t3_thread_read) #18316 asks for the pin to be readable from MCP. feat(threads): add per-thread auto-settle switch #11846 added the per-thread switch this builds on.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server (t3-code MCP thread toolkit)

Problem or use case

An agent often knows before the merge that the thread is not done when its PR merges. In my case the agent opened a PR into a release branch, babysat it, and merged it when I asked. The ticket still had two steps: queue the Test deploy, which nothing triggered automatically, and run a storage copy after the next prod release. The agent listed both in its final reply. The thread auto-settled 20 seconds after that turn ended.

The per-thread switch from #11846 (thread menu, Auto-settle behavior → Disabled) is the right tool, but only a person can flip it. t3_thread_organize offers pin, unpin, snooze, unsnooze, settle, unsettle, archive, unarchive and mark_unread. The thread.auto-settle.set command exists (Orchestrator.ts:3118), but no MCP tool dispatches it.

What an agent can do today (main @ 5ffe045, tested on 0.1.1-nightly.20261019.3360):

• unsettle before the merge sets settledOverride: "active", but any message dispatch clears it (Orchestrator.ts:4930). Tested: unsettle, send one message, and the override is null again. A PR-watch wake is enough to undo it.
• unlink_pull_request drops the PR status beside the thread. From the code, the sweep would then find the same merged PR through the branch lookup anyway.
• Snooze only defers. The thread settles at the first sweep after it wakes.
• pin works, since isAutoSettlementCandidate skips pinned threads (ThreadSettlementService.ts:164). But it fills the user's pinned list with threads they never chose to pin.

Proposed behavior

• Add two actions to t3_thread_organize, for example disable_auto_settle and enable_auto_settle, that dispatch thread.auto-settle.set under the same archived-thread rules as the other actions.
• Return the switch from t3_thread_read and t3_thread_list (for example autoSettleEnabled) so an agent can read back what it set. Neither tool shows it today, nor the pin (Expose pinned state in orchestrator MCP thread tools (t3_thread_list / t3_thread_read) #18316).

Manual settle keeps working, as it does with the menu switch.

Why this matters

T3 asks agents to link every PR they open, so most agent threads have a linked PR, and merge settlement decides when they leave the active list. The agent writing the handoff knows whether work remains after the merge. Letting it set the switch the user already has puts that knowledge where the settlement rule reads it.

Smallest useful scope

Two t3_thread_organize actions over the existing command, plus one read-back field. No new settlement rules and no new setting.

Alternatives considered

• A grace period after an agent merge (Auto-settle on merge: give the user time to read the agent's final reply when the agent merged the PR itself #14930). It gives the user time to read the last reply, but here the remaining work lasts days, until a prod release.
• Turning off settle-on-merge for the project. Too broad: most threads should still settle on merge.
• Keeping the unsettle override through agent messages (one of the fixes in [Bug]: An agent-orchestrated thread re-settles after every turn once its linked PRs merged, killing its background commands, and MCP has no way to opt it out #19263). That would also work, but unsettle is a one-off action, and the switch already exists for the durable case.
• Fixing [Bug]: Thread auto-settles while the agent is still waiting on a background command #17625 alone. That holds settlement only while a background command runs; nothing was running here, and the remaining work outlives any command.

Risks or tradeoffs

An agent could leave finished threads in the active list. The switch is visible in the thread menu, the user can still settle by hand, and the agent can turn it back on once its follow-up is done.

Also

docs/user/thread-sidebar.md:65 still says "Pinning does not prevent automatic settlement", which #11711 changed. #19263 noted this too.