[Bug]: Queued agent messages silently switch a thread back to an account the user explicitly left #22457

Area

apps/server, orchestration-v2 queue delivery

Summary

An older queued agent message can silently switch a thread back to the Claude account the user explicitly left. The user repeatedly selected Claude Default, successfully ran a turn there, and then found the thread running on Claude Work again as older messages drained.

Please reconsider queue-time provider pinning for ordinary agent messages and thread-bound scheduled wakes. Changing the thread's selected account should govern its pending messages, or the UI should offer an explicit choice about those messages. An automatic queued delivery should not silently undo the user's later account selection.

This is a focused follow-up to #19376 on the latest published Nightly. That issue was closed as an umbrella and its response said queued model pinning was intentional, with an invitation to report remaining concrete vectors on the latest Nightly. This report asks to change that behavior for messages which did not explicitly request a provider. It is related to #21705, but does not depend on a usage-limit failure or an exhausted account. #21313 addressed monitor notifications; the messages here are ordinary MCP traffic and a thread-bound scheduled wake.

Steps to reproduce

1. Run a thread on Claude account A. Queue an ordinary t3_thread_send message without an explicit provider override while A is working. A thread-bound scheduled wake can also enter the queue in this state.
2. Before that message starts, explicitly switch the thread to account B and send a new turn on B.
3. Let the B turn complete and the older queued message start.
4. Inspect the running provider and the durable thread model selection.

These steps describe the observed production sequence and source path. I have not rerun the sequence in an isolated clean installation.

Expected behavior

The user's later explicit account selection remains authoritative. Pending ordinary messages run on B. If retaining A is necessary, expose that pin and ask the user how to handle the pending messages when switching accounts. At minimum, running a previously pinned message should not silently change the thread's durable selection back to A.

Actual behavior

UTC on October 20, 2026, from the durable run records of one thread:

The thread configuration was observed on Work after the older messages resumed. The agent/MCP message and scheduled wake both had notification: null. The ordinary MCP message had no scheduled-task ID. The successful Default run and subsequent Work runs used the same Claude Opus 5.5 model. Fast mode was false throughout.

Source and release check

Observed on Linux desktop Nightly 0.1.1-nightly.20261020.3411, the latest published release checked at filing time. Its release commit is d36b7da2485bc889b320a285deea181f637d760a.

The installed server bundle and pinned release source agree on the relevant policy:

• followsCurrentConversation and queuedRunModelSelection use the current thread selection only for eligible monitor notifications. Ordinary queued messages retain run.modelSelection.
• Queue delivery compares that retained selection with the current thread selection and plans a switch targeting the older queued selection.
• Thread-bound scheduled tasks now call sendToThread without a model override. That fixes creation-time pinning, but a wake queued before the account switch still encounters the queue-time policy above.

Installed server bundle member apps/server/dist/binCli-Bm8tVhP8.mjs SHA-256: 118f2efa1a936c31cda36f679551a2ef85b28c496497cd752e2c0c1d64fe8df3. This is installed-byte inspection and a live incident, not a new source build or an isolated end-to-end test. No local patch to this policy was made.

Impact

Major degradation or frequent failure. Repeated explicit account switches appear not to stick. Agent traffic and scheduled messages can move active work onto an unwanted subscription and consume its quota. The user must inspect and reconcile the queue to keep the requested account in use.

Workaround

We interrupted the remaining Work turn, confirmed the queue had no remaining entries, explicitly configured Default, and resumed the unfinished task. The new run was verified running on Default. This repaired the affected thread but did not change queue semantics.