Auto-settle on merge re-settles a thread after every later run, and agents can't opt a thread out over MCP

Version: desktop app as of 2026-10-27. Source references are from main at da7c4f234d.

What happens

A thread's linked PR merges, but the thread still has work to do after the merge: a production check, deploy verification, or a follow-up round that another agent asks for. Each time one of its runs ends, the thread is auto-settled with settledAt equal to that run's completedAt. An orchestrating agent wakes it again with t3_thread_send, the next run ends, and the thread is settled again. In one day, one thread was settled 5 times this way. On all 5 threads I checked, settledAt matched the last run's completedAt to the millisecond.

Why (from the source)

ThreadSettlementService.ts pullRequestSettles settles when the PR's mergedAt is at or after max(createdAt, latestUserAuthoredMessageAt).
ProjectionStore.ts sets latestUserAuthoredMessageAt only from messages with createdBy === "user". A message sent by another agent through MCP t3_thread_send has createdBy: "agent", so it never moves that anchor. The merge therefore keeps qualifying after every later run.
The per-thread switch (autoSettleDisabledAt, feat(threads): add per-thread auto-settle switch #11846) can't be set over MCP: t3_thread_organize offers only pin, snooze, settle, unsettle, archive and mark_unread. unsettle doesn't hold either, because the next run's activity clears the override.

Requests (either one fixes it)

Treat a run requested after mergedAt (or an agent-authored message) as activity for the merge rule, so work started after a merge isn't settled when that run ends.
Expose the per-thread auto-settle switch through MCP, for example t3_thread_organize actions disable_auto_settle and enable_auto_settle, so an orchestrating agent can keep a thread open until its follow-up work is done.

Related: #26083 (the same merge rule racing a background-task wake turn). Current workaround: turn off auto-settle on merge in settings.

feat(server): agents can turn a thread's auto-settle off and on over MCP

Opened a PR that implements request (1): intentional MCP/CLI agent sends now count as resume anchors (latestResumingMessageAt), so merge auto-settle no longer drops a settled thread back into Settled after a follow-up turn. Automatic server/provider wakes are unchanged.

#33995

feat(server): agents can turn a thread's auto-settle off and on over MCP

One more case of this, with numbers from my local store (0.1.9, macOS).

A thread had a linked PR that merged. After that, every turn in it was started by a message sent from another thread (t3_thread_send) or by a scheduled task. Those do not move the "latest user-authored message" time, so the merged PR kept winning the check in pullRequestSettles and the thread was settled again right after each turn ended, 107 ms after the last one. Four times in two days, each time while the final message asked me a question.

Over 7 days the event log shows 108 thread.settled events with a server:auto-settle: command id. In 5 of them the last agent message before the settle held an open question for me.

What would have helped: a message that reaches the thread through t3_thread_send on the user's behalf counts as activity for this check, or agents can set the per-thread opt-out over MCP as described above. I turned sidebarAutoSettleOnMerge off for now.

feat(server): agents can turn a thread's auto-settle off and on over MCP

Navigation Menu

Repository navigation

Auto-settle on merge re-settles a thread after every later run, and agents can't opt a thread out over MCP #26097

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Auto-settle on merge re-settles a thread after every later run, and agents can't opt a thread out over MCP #26097

Description

Activity

johnatfreecoffee commented on Nov 10, 2026

pjmuller commented on Nov 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions