Settle on merge: wake the agent and let it settle the thread if its task is done, instead of settling automatically

[PastaPastaPasta]

Before submitting

• I searched existing issues and Ideas discussions. This is a different fix for the problem behind several of them; see Related below.

Area

apps/server (ThreadSettlementService, PullRequestWatchReactor, t3-code MCP)

Problem

"Auto-settle merged threads" (sidebarAutoSettleOnMerge, on by default) treats a merge as proof that the thread's task is done. Often it isn't. The PR is one step of a larger task: tag a release, deploy, run a data repair, verify production, open the next PR in a stack, or report back to an orchestrator. A merge rule can't tell these cases apart. The agent can, because it knows what it was asked to do.

What happens today (main @ 210b2e7c6a):

1. The agent merges the PR itself (or a merge queue lands it), says "I'll deploy once main CI is green", and ends its turn.
2. pullRequestSettles sees a merge newer than the last user message, and the run.updated sweep (L641) settles the thread as soon as the turn completes.
3. The PR watch ends on merge without waking the agent. A close does wake it. Settling also closes idle terminals, runs runOnSettle, and detaches the provider session.
4. Nothing ever re-invokes the thread, and the promised follow-up silently never happens.

A real case: the agent merged a PR, said it would tag and deploy once main CI passed, and ended its turn. The thread settled. The tag, deploy, DB repair and production check sat undone for two days, until I went looking.

The workarounds each fix one symptom and add a cost:

• Turning merge-settle off globally leaves every finished thread in the active list for days.
• The per-thread Auto-settle behavior → Disabled switch is UI-only (Let agents turn a thread's auto-settle off through the t3-code MCP #23485) and has to be set before the merge.
• Pinning, snoozing, and unsettle don't stick: pins fill the pinned list, a snooze only defers, and the next message clears unsettle.
• Agent instructions like "never end a turn after a merge with follow-up pending" work, but they mean waiting out CI and deploys inside one turn.

Proposal

Replace the programmatic settle-on-merge with an agent-judged one. When a linked PR merges, wake the thread's agent once and let it decide whether the task is done.

1. On merge, wake instead of settle. Post one message into the thread, like the existing closed notice. For example: "Pull request #N (url) merged. If the task you were given is now complete, call t3_thread_organize with action: "settle" and end your turn. If work remains (deploy, release, more PRs, reporting back), continue it and don't settle."
2. The agent settles itself. t3_thread_organize → settle already arms "settle when this turn ends" for the calling agent (settleThread), so no new settle primitive is needed.
3. If it doesn't settle, nothing happens automatically. The thread stays active, and the inactivity rule (sidebarAutoSettleAfterDays) still applies as the backstop.
4. A merge during the agent's own turn is handled the same way: the merge notice is delivered at the end of that turn (or the turn-end settle check asks the same question), instead of settling the instant the run completes. This also covers Auto-settle on merge: give the user time to read the agent's final reply when the agent merged the PR itself #14930 (the reply settles before the user can read it).
5. The existing safeguards stay. Skip the wake when the thread has no live agent context to ask: an archived thread, a subagent child, a thread already settled, or one with auto-settle disabled. Keep the current "another open linked PR blocks merge-settle" rule as the "is there anything left to ask about" gate. When several linked PRs merge in one sweep, send one wake.

Setting shape: make sidebarAutoSettleOnMerge a three-way mode (ask-agent / immediate / off), global with the existing per-project override. I'd suggest ask-agent as the default for threads with a live agent session, with immediate kept for people who want today's behaviour. Merges on threads with no agent session (user-created, never run) could keep settling immediately.

Why this, rather than the narrower proposals

• It puts the "is this done?" decision with the only party that knows the answer, at the moment it matters. Opt-outs (Let agents turn a thread's auto-settle off through the t3-code MCP #23485) and registered follow-ups ([Feature]: Post-merge follow-ups — let a thread register work to run when its PR merges or reaches a release branch #18044) both need the agent to predict before the merge that work will remain.
• It reuses existing pieces: the PR watch's terminal notice, the self-settle-at-turn-end path, and the inactivity backstop.
• It fixes the silent merge at the same time (watch_pull_request ends silently on merge, so agents never verify merge-queue landings #25160): the agent learns that its PR landed, so it can verify a merge-queue landing.

Cost: one extra short agent turn per merged PR on threads that were going to settle anyway. Since the agent's answer is usually "done, settle", this turn should be cheap. The setting keeps immediate for anyone who doesn't want to pay it.

Related

• watch_pull_request ends silently on merge, so agents never verify merge-queue landings #25160: watch_pull_request ends silently on merge. That's the wake this proposal would add. [Bug]: watch_pull_request ends silently, so the thread never hears of the author's push or reply #22183 is the same silent ending without a merge.
• Auto-settle on merge: give the user time to read the agent's final reply when the agent merged the PR itself #14930: settle-on-merge fires before the user can read the agent's final reply.
• Let agents turn a thread's auto-settle off through the t3-code MCP #23485: let agents turn a thread's auto-settle off through MCP. This proposal makes that opt-out mostly unnecessary.
• [Feature]: Post-merge follow-ups — let a thread register work to run when its PR merges or reaches a release branch #18044: post-merge follow-ups registered in advance. This proposal is the zero-registration version.
• [Feature request] Run an agent automation/prompt on auto settled thread #16820 / Run a configurable prompt or skill when settling a thread #19004: run a prompt on settle. Those settle no matter what the prompt finds; this lets the agent's answer decide.
• [Feature]: Auto Settle, hide a running thread and settle it silently when it's done #13630 / [Bug]: Thread auto-settles while the agent is still waiting on a background command #17625 / [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: settle-when-idle and settle killing background work.