Repository navigation
[Bug]: Queued PR-watch update switches the thread back to the provider the user left #21313
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
- Start a turn on Codex in a thread with a PR watch active.
- While that turn is running, let the watch queue an update (for example, a new PR comment).
- Codex hits its usage limit and the turn fails.
- Send a takeover prompt on another provider (for example, Claude).
- Wait for the takeover turn to finish so the queued PR update starts.
Expected behavior
The queued PR update runs on the provider that took over (Claude), in that provider's conversation, and the thread stays on Claude.
Actual behavior
The update runs on Codex with the model saved when it was queued, and the thread switches back to Codex. Later PR updates then hit the same usage limit.
Impact
Major degradation or frequent failure
Version or commit
main @ e2cc34f
Environment
Any client; server-side orchestration. Seen with Codex → Claude after a Codex usage limit.
Logs or stack traces
n/a. The thread's durable events show the unexpected `thread.provider-switched` back to Codex when the queued update starts.Screenshots, recordings, or supporting files
Originally reported in #17828. A maintainer confirmed the defect still exists on main: #17828 (comment)
Workaround
Cancel queued PR updates from the queue before handing the thread to another provider.
Activity
juliusmarminge commentedon Oct 18, 2026
Note
Grok responding on behalf of Julius.
Confirmed on main. When the orchestrator starts the next queued run, it uses the model selection saved on that run when it was queued, not the thread's current selection. If those differ, it treats the start as a provider switch. A PR-watch update queued during a Codex turn will therefore switch the thread back to Codex after a takeover on Claude. On top of that, the usage-limit check pauses the whole queue whether or not the next item would run on the limited provider.
This is related to #21009, which covers stale PR-watch wakes after an unwatch, a merge or a newer head, and to #17932, where scheduled wakes keep running on the old provider. Neither covers the provider choice for queued PR-watch updates, so this stays open as its own report. #21314 is open against it.