fix(server,mobile): a model pick applies to the message it was sent with#25587

🟠 High orchestration-v2/Orchestrator.ts:5272

A start_immediately manual continuation can switch providers and start on a queued message’s model instead of continuing the interrupted run’s provider conversation. This block inherits the newest queued run’s model before determining whether the dispatch will actually join the queue; gate the inheritance on actual queueing so non-queued dispatches keep the thread model.

✅ Resolved in 53d61f53d93eaec70c3c5803ee32a6fd0173f2c5

Valid, fixed in 53d61f53d9. The rule now runs after the queue decision and applies only when the message actually queues (shouldQueue), so a start_immediately continuation after a Stop keeps the thread model. The integration test now covers that: it stops the thread with a held Claude pick queued, then sends an unpicked start_immediately message, and asserts it runs on Codex. It fails without the gate.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

External image Major · Functional Correctness · Quick win

Exclude server-created user messages from queued-pick inheritance.

dispatchRuntimeRequestRespond creates an answer with createdBy: "user", creationSource: "server", and no modelSelection (Lines 7976-7987). If a run is queued, this condition makes that server-created answer inherit the queued run’s pick instead of retaining the thread selection. Restrict inheritance to eligible client-originated dispatches; the PR objective keeps server-created messages unchanged.

✅ Confirmed as addressed by @vitalyiegorov

Valid, fixed in bd05aac3b7. Inheritance now also requires sentByUserFromClient (user-created, web or mobile, not a scheduled task), so a server-created answer from dispatchRuntimeRequestRespond keeps the thread selection. The integration test queues a server-sourced unpicked message behind a Claude pick and asserts it stays on Codex; it fails without the check.

@vitalyiegorov The supplied code confirms that inheritance now requires sentByUserFromClient. Server-created answers from dispatchRuntimeRequestRespond keep the thread selection. This addresses the finding.

📝 I couldn't check this conversation for new learnings, so no new learning was saved.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

External image Major · Functional Correctness · Quick win

Apply queued-pick inheritance only when the new run joins the queue.

If a Claude-picked run is held in the queue and no run is active, an unpicked start_immediately command inherits Claude here. The command then starts ahead of the held run, although the thread can still be on Codex. Determine whether the dispatch will queue before selecting a queued predecessor; immediate starts should use the thread selection.

✅ Addressed in commit 53d61f5

Already fixed in 88f20f5cf6 (this comment is on 96d91ef). Inheritance is gated on shouldQueue, and the integration test covers an unpicked start_immediately message after a Stop with a held Claude pick: it runs on Codex.

@vitalyiegorov Confirmed in the supplied code: queued-pick inheritance requires shouldQueue. An unpicked start_immediately message after Stop therefore keeps the thread’s Codex selection instead of inheriting the held Claude pick. This addresses the finding.

📝 I couldn't check this conversation for new learnings, so no new learning was saved.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Make the delivered-pick release wait for draft hydration.

releaseDeliveredComposerModelPick returns without change when the draft is absent. It does not await or start draft hydration, and the delivery path does not await it before the release. If a queued message delivers before persisted drafts load, the release is a no-op. Hydration then merges the persisted draft, and that draft still holds the delivered pick. A later unpicked follow-up can reuse that pick. The app has no startup guarantee in the inspected code that prevents this order.

Awaiting hydration before the release closes this gap. The delivery path is already async, so the call site can await the helper.

✅ Confirmed as addressed by @vitalyiegorov

Fixed in a65a1d4902. releaseDeliveredComposerModelPick now awaits waitForComposerDraftsLoaded() before it clears the pick, and the outbox drain awaits it.

@vitalyiegorov Thanks for fixing this in a65a1d4902. Waiting for draft hydration and awaiting the helper in the outbox drain addresses the reported race.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

External image Major · Functional Correctness · Heavy lift

Resolve monitor predecessors against their delivery-time selection.

If a Claude pick is queued, followed by an app-owned monitor message, this helper returns the current thread selection for the monitor message. The monitor message instead follows the thread selection when it starts, after the Claude pick. An unpicked message queued behind the monitor therefore stores the old selection and switches the thread back. Derive the selection from the queued delivery sequence rather than the monitor message’s current-thread fallback.

External image Major · Functional Correctness · Heavy lift

Reconcile inherited selections when their queued predecessor is removed.

If a user cancels a queued Claude pick before it starts, a later unpicked message retains the Claude selection copied here. dispatchQueuedRunCancel cancels the picked run but does not update the later run. startNextQueuedRun then starts that unpicked message on Claude and changes the thread selection, despite the canceled pick. Preserve the predecessor relationship or recompute affected queued selections after cancellation.

Monitor predecessor: fixed in a65a1d4902. The lookup now skips queued monitor updates, since they follow whatever runs before them, and inherits the newest queued run that has its own selection. There's a regression step in ProviderSwitch.integration.test.ts (pick, then monitor, then an unpicked follow-up stays on the pick).

Cancel/reorder: leaving this as is on purpose. The follow-up keeps the provider the composer showed when the user sent it, the same as an explicitly picked queued message. Re-deriving it later would make a sent message silently change provider. Recomputing later queued runs on cancel would need a stored "inherited" marker on runs (a contract change), which is out of scope for this fix.

@vitalyiegorov The supplied code confirms the monitor-predecessor fix. The lookup skips runs that satisfy followsCurrentConversation and copies the newest remaining queued run’s modelSelection.

I withdraw the cancel/reorder finding. Under the intended send-time selection contract, each queued user message keeps its stored selection. Canceling or reordering another message must not silently change that selection. No inherited-selection marker or recomputation is required for this fix.

I did not run the regression test.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

External image Major · Functional Correctness · Quick win

Do not inherit from a run that a goal command will pass.

If a queued Claude pick exists and a Codex /goal command stops the active run, goalStopRunId places the new command at queue position 1. This lookup still copies Claude from the last queued run. The goal command then runs on Claude before the picked message runs. Use the thread selection when the new command goes ahead of the queued runs.

✅ Addressed in commit a65a1d4

Fixed in a65a1d4902. A goal command that stops the active run (goalStopRunId) goes ahead of the queue, so it no longer inherits a queued pick. It keeps the thread selection.

@vitalyiegorov The supplied code confirms the fix. The goalStopRunId === undefined guard prevents a goal command placed ahead of the queue from inheriting a queued pick. Without an explicit pick, the command keeps the thread selection. Ordinary queued follow-ups still inherit as intended.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

🟠 High orchestration-v2/Orchestrator.ts:5495

A queued message with no explicit modelSelection is validated against the thread’s current model, so a provider-specific goal command such as /goal pause is rejected even when its queued destination supports it. newestQueuedPick updates modelSelection only after goalDriverFor and ensureGoalCommandSupported have run; resolve the inherited queued model before those checks.

Fixed in c56713aeb8, the other way round: goal commands no longer inherit a queued pick at all (parsedGoalCommand === null gates the lookup). The provider they run on is now the same one goalDriverFor and ensureGoalCommandSupported checked. Resolving the pick before those checks wouldn't work, because the goal-stop decision feeds into whether the command queues behind the pick. Goal commands are about the conversation that's currently active, so the thread's provider is the right target.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.