[Bug]: Mobile keeps an old model after the same thread changes on desktop#10202

openedSep 5, 2026byBBeLazy167

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

What happened

I started a thread on mobile with GPT-5.6 Sol and low reasoning. After several messages, I continued the same thread on desktop and switched to GPT-6 Astra with medium reasoning. When I returned to mobile, its composer still showed Sol. Desktop showed the newer choice.

The saved server history later shows a request for Sol again and a change back to Sol. This may affect the next message's model, rather than only its displayed label.

Steps to reproduce the reported flow

Create a thread on mobile and select model A.
Send messages and continue working in that thread.
Open the same thread on desktop, select model B, and send messages using B.
Return to mobile and start typing in the same thread.
Check the model shown in the composer. In this case it still showed A.
In a temporary test thread, send from mobile and inspect the requested model on the server.

Expected behavior

After a local model choice has been used and confirmed by the server, mobile should follow later model changes to the same thread. A new, unsent choice made deliberately on mobile should still be preserved.

Evidence from the affected thread

A read-only check of the local server database found these events on September 5, 2026, in UTC:

Time	Saved event
19:29:02	Thread created with `gpt-5.6-sol`, reasoning `low`
20:21:20	Model changed to `gpt-6-astra`, reasoning `medium`, followed by a turn request using that selection
20:24:54 and 20:26:06	Further turn requests used Astra
20:37:14	Model changed back to Sol, reasoning `low`, followed by a turn request using that selection

The later request does not identify its originating device. These records confirm the model reversal, but do not by themselves prove that mobile caused it. No thread contents or state were changed during the check.

Matching behavior in the code

At d92dca74eb7b7c6068619752f5b9a55c0e36f352, the mobile composer prefers the local draft's model over the thread's server model for both display and send. After enqueueing a message, it clears draft content without requesting model-selection removal.

The draft clear helper retains that model by default. An already-used local choice can therefore continue overriding newer server state.

A small test extracted the real draft-clear helper and used the display/send precedence expressions from the source. It seeded a local selection of A, cleared the sent message, then supplied server model B:

text

1	1.0.3-era code: mobile displays A and selects A for next send
2	checkout d92dca74e: mobile displays A and selects A for next send

This is a focused state-logic reproduction, not a full device or provider execution test. It assumes an existing thread-local model override; the exact path that populated this phone's override has not been captured.

Version and environment

Native iOS app: 1.0.3, on iOS 27 as reported by the user.
Provider: Codex.
Desktop/server build, phone OTA runtime, and connection mode: not collected.
The matching state behavior was tested in 3da7f9c5c and d92dca74e. We should not assume the newer mobile release fixes it.

Suggested fix and verification

Treat a model choice as an unsent override until the server confirms its use, then let the composer follow the thread's saved model. Preserve a newer local choice made while an earlier send is still pending, and retain recoverable settings when sending fails.

Test the mobile-to-desktop-to-mobile handoff, the next send's requested model, a failed send, and a deliberate unsent mobile choice. Also cover an empty composer and a draft containing text.

Related work

#6508 concerns defaults for new threads, rather than changes to the same thread on another device.
#5421 concerns web provider-option precedence.
#9372 updates remembered mobile options for future threads. Its stated scope does not clear an existing thread's stale draft override.

Prepared with GPT-6 in Codex from the user's observations, read-only server records, and a focused source test.

JJulius MarmingeSep 5, 2026

Triage

Confirmed as a real mobile composer-state bug, not a duplicate of #6508, #5421, or PR #9372.

What we verified

On current main, the mobile thread composer still prefers a persisted local draft model over the server thread model for both display and the next send:

1	const modelSelection = selectedDraft?.modelSelection ?? selectedThread?.modelSelection ?? null;

1	const modelSelection = draft.modelSelection ?? thread.modelSelection;

After enqueue, existing-thread send calls clearComposerDraftContent without clearModelSelection: true. The draft-clear helper keeps modelSelection by default. That retain-after-send behavior is covered by use-composer-drafts.test.ts ("clears sent content without clearing the selected model or workspace").

New-task send already passes clearModelSelection: true. Existing threads do not, so an already-used local pick can keep winning after desktop changes the same thread’s model.

If the user then sends from mobile, outbox drain compares that draft/queued model to thread.modelSelection and will updateThreadMetadata when they differ. That matches the reported later reversal to Sol. The saved events do not name the originating device, so they confirm the reversal, not the device by themselves.

The cited commit d92dca74e is still ancestral; the same precedence is present on current HEAD.

Related work (not duplicates)

#6508 is about new-thread defaults, not same-thread multi-device sync.
#5421 is web provider-option precedence.
PR #9372 updates remembered mobile options for future threads. It does not clear a stale same-thread draft override. Landing it first could even copy that stale model into sticky defaults.

Web already distinguishes explicit vs inherited draft models (modelSelectionExplicit) and strips non-explicit model seeds from empty draft sessions. Mobile thread drafts have no equivalent.

Suggested fix

Treat draft.modelSelection as an unsent override:

After the server has confirmed the local choice (or after a successful enqueue, if we accept that approximation), drop the thread-draft model so later compose/send follow thread.modelSelection.
Keep a newer local pick made while a send is still pending.
Restore the draft model on failed send / outbox recovery.
Cover empty composer and a draft that still has text.

Also decide whether already-persisted 1.0.3 thread drafts should be stripped on hydrate when they carry only a bare modelSelection (similar to the existing new-task: stale-model strip).

Verification

Need mobile→desktop→mobile on the same thread, plus: next send’s requested model, failed send, deliberate unsent mobile pick, empty vs non-empty draft. Provider: Codex. Connection mode does not change the local draft store.

Labels

bug, accepted, via-triage (remove needs-triage)

BBeLazy167Sep 5, 2026

Opened #10205 with a fix and regression tests against f8b4c464b.

The user's observation that chat streaming still works fits the source behavior. The mobile composer prefers its persisted draft model for both display and send. A fresh server model therefore cannot win while that local override remains. Outbox delivery then syncs the queued selection back into thread metadata when it differs from the server. This explains how a stale local choice can reverse the thread model without streaming being broken.

The new tests use the actual draft store, outbox manager, and delivery cleanup, with native storage mocked. Running them against the unmodified production files gives:

text

1	Tests 4 failed \| 5 passed \| 18 skipped

All four failures show the confirmed model still retained in the draft. They cover an empty composer, new text typed during delivery, attachments and other settings, and a successful send whose local outbox cleanup fails.

With the fix, the same nine new tests pass. The three affected suites together pass all 90 tests. Mobile typechecking passes. Scoped lint has only an existing effect-dependency warning, confirmed against the base file.

The patch waits for server acceptance before releasing the matching override. A reference check preserves a newer pick made during delivery, including reselecting the same model. Tests cover restart persistence, inheriting the desktop model and reasoning options for subsequent queued settings, failed-send recovery, and preserving a different unsent choice when an offline message begins delivery.

For the hydrate decision raised in triage, this PR leaves old drafts intact. A model-only draft may be a deliberate unsent choice, and the current format does not record enough history to distinguish it from a previously sent choice. An existing override is released after its next accepted mobile send. Select the intended model on mobile before that first send.

This is source-level regression evidence, not a physical iPhone reproduction. It does not establish which device originated the historical model reversal. The remaining device check is mobile A → desktop B → mobile, verifying both the picker and the next requested model, then repeating with unsent text and a deliberate mobile choice C. The fix is proposed, not merged or shipped to 1.0.3.

BBeLazy167Sep 5, 2026

The deliberate-coder review found and fixed a persistence gap in the first PR revision. Draft updates use a 200 ms debounce. The original restart test manually flushed after delivery, which hid a window where outbox removal had completed but disk still held the old model.

Commit ee650b4b6 in #10205 now flushes the cleared override before removing the delivered outbox entry. If writing fails, the existing acknowledged-message cleanup path retries persistence before removal. Newer draft edits remain intact.

Two strengthened immediate-restart cases and a draft-write-failure case failed against the first PR revision and pass with the follow-up. All 91 tests in the three focused suites pass, and mobile typechecking passes. Scoped lint still reports only the previously verified dependency warning.

The code-quality review used Monid CLI web search and the official React state-structure guidance and Redux guidance on overlapping optimistic updates. These support avoiding a permanent local copy of server state and preserving newer edits when earlier work completes. The proposed fix continues using the existing draft store and outbox; it adds no synchronization library or wire format.

Physical iPhone handoff verification remains pending. This update does not change the documented decision to preserve old drafts on hydrate.

AAlexChambers16d ago

Additional evidence of the reported mobile selection reversal on October 9, 2026, affecting Codex account selection on iPhone mobile version 1.4.1 with desktop/server version 0.0.45.

The user reported that an existing thread started using account A could continue on desktop after switching to a working compatible account B, but mobile remained stuck on A. Account A had been removed from the configured providers.

Read-only inspection of that thread's saved events found the following account changes:

October 9, 2026, UTC	Client	Recorded account choice
07:31:06	Desktop	Working account B
08:37:02	Mobile 1.4.1	Removed account A
08:38:37	Desktop	Working account B
09:34:32	Mobile 1.4.1	Removed account A
09:39:24	Desktop	Working account B

Unlike the original report's records, these model-selection events contain origin metadata identifying mobile or desktop and the app version. The mobile command IDs end in :model-selection. They confirm that mobile submitted the removed account selection after desktop changed the same thread to a working account.

Source inspection found the same precedence described in this issue: a stored mobile draft selection wins over the server thread selection for display and sending. The iPhone's local draft storage was not inspected, so the exact saved override is inferred from that code and the recorded mobile requests.

Recovery is also blocked by #14798: the existing-thread mobile picker hides compatible replacement accounts. The recorded Codex account snapshots shared the same continuation group. Please include this removed-account case when verifying stale-selection cleanup and picker compatibility, while preserving deliberate unsent account choices and failed-send recovery.

These versions use Orchestrator V1. This evidence does not establish whether the same case reproduces on V2. The report remains relevant to users on these releases despite this issue's closure. The current workaround is to continue on desktop.

No fresh device reproduction, database mutation, or local-storage reset was performed. Account identifiers, paths, and conversation content are omitted.