Repository navigation
[Bug]: Auto-settle on PR merge settles the thread before the agent hears that the PR merged #29896
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Turn on Settle on merge.
- Have an agent open a PR in a repository that uses GitHub's merge queue, add it to the queue and call
watch_pull_request. - The agent gets the "All N required checks passed" wake and ends its turn with work planned for after the merge, for example "I'll open the next PR in the series once this one merges".
- The queue merges the PR.
Expected behavior
The agent gets a turn that tells it the PR merged, and the thread settles only after that turn ends with nothing left pending.
Actual behavior
As soon as the PR sync sees merged, the thread is auto-settled and its provider session is detached. In one event log the settle came 14 ms after the sync event that saw the merge. The agent never runs again, and the work it planned after the merge is not done until someone unsettles the thread and prompts it.
Impact
Major degradation or frequent failure
Version or commit
0.1.7-nightly.20261101.4048 (server); main at d8a829e
Environment
Linux x86_64, T3 Code server running as a service, Claude provider (claude-opus-5-5)
Logs or stack traces
23:42:40 PR watch wake "All 5 checks passed"; agent replies in 1.5 s and ends its turn
23:42:52 PR merged by the merge queue
23:43:46 PR sync sees merged; watch ends without a wake
23:43:46 auto-settle 14 ms later; provider session detachedIn the same install, six threads were unsettled by hand one evening. All six had been auto-settled 35 to 78 minutes earlier when their PR merged, and four still had work left: another PR to ship, a second PR half done, or a test run still going.
Workaround
Turn off Settle on merge.
Related: #25160 is the missing merge wake. This issue is the settle side, which settles before that wake could be delivered. #26097 and #27052 are other settle-on-merge problems with different causes. #29854 fixes this together with #25160.
Written by Claude Opus 5.5 in Claude Code, run from T3 Code.
Activity
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Not reproduced in a running app; this was code reading plus a unit test on origin/main 62dc589. A live run needs a GitHub repo with a merge queue and a real agent turn, which I did not set up. The failing test is on branch factory/repro-29896 (56bb7b1). It adds a case to packages/shared/src/orchestrationV2PendingBackgroundWork.test.ts: a completed run with a watched PR link whose snapshot state is 'merged'. derivePendingBackgroundWork returns [] on main, where the test expects an awaited 'pull-request-watch' task that holds settlement. Command:
cd packages/shared && vp test run src/orchestrationV2PendingBackgroundWork.test.ts, which gives 1 failed and 20 passed. In code, PullRequestWatchReactor ends a merged PR's watch through record(target, null) and ended(target, 'merged') with no wake, pullRequestWatchTasks drops links with snapshot.state === 'merged', and ThreadSettlementService then finds nothing holding the thread and dispatches thread.auto-settle as soon as a sync stores the merged snapshot.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.