Sign up
View stargazers13Sign up

[Bug]: Switching provider instance (e.g. another Claude Code account) on one device isn't synced; next send from another device reverts it#18762

opened13d agobyMmurmaider227

Before submitting

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

Area

apps/web, apps/mobile

Steps to reproduce

  1. Configure two (or more) provider instances of the same driver, e.g. two Claude Code instances backed by different accounts (Claude A, Claude B).
  2. Open the same thread on the desktop app and on the mobile app (or two desktop/web clients). Both show Claude A.
  3. On device 1 (e.g. phone), switch the thread's provider instance to Claude B (optionally send a message — it runs on Claude B).
  4. On device 2 (e.g. desktop), without manually refreshing or touching the provider picker, send the next message.

Expected behavior

Device 2 picks up the provider instance change made on device 1 (composer/picker shows Claude B), and the next message from device 2 runs on Claude B. A newer explicit pick made on device 2 should still win.

Actual behavior

Device 2 keeps showing the old instance (Claude A). When a message is sent from device 2, the thread is silently switched back to Claude A — the change made on device 1 is reverted. Works the same in both directions (desktop → mobile and mobile → desktop).

This looks like the cross-instance variant of #15195 (which covers same-instance model switches) and the same silent-revert mechanism as #10684 / #10202 / #13483. Those were closed by #2829 (server-side thread.model-selection.set / thread.model-selection-updated), but on current nightly the client still appears to prefer its locally stored draft selection (selectedInstanceId / modelSelectionByProvider in the composer draft) over the server thread selection, and writes it back on send.

Impact

Major degradation or frequent failure

(Especially painful with multiple accounts: switching to another account because one hit its usage limit gets undone as soon as you send from another device.)

Version or commit

T3 Code Nightly 0.0.46-nightly (October 2026)

Environment

Desktop: Windows 11, T3 Code nightly desktop app. Mobile: T3 Code mobile app (nightly). Provider: multiple Claude Code instances (different accounts).

Workaround

Re-select the provider instance manually on every device before sending.

JJulius Marminge13d ago

Note

Grok responding on behalf of Julius.

Open #18612 already targets this silent-revert: after a send is accepted it releases the local composer override (modelSelectionByProvider / active provider, including instanceId) so later clients follow the server thread selection. Same underlying issue as #15195 (same-instance model switches); this report covers the cross-instance / multi-account variant.

DDonutsDelivery11d ago
Synced from GitHub

Mechanism analysis for this (and the other silent-revert symptoms): the server-side dispatch chain makes any writer authoritative, not just a stale composer draft.

  • The dispatch resolves command.modelSelection ?? projection.thread.modelSelection — any caller that omits the selection falls back to the thread's stored record (Orchestrator.ts:4747).
  • The server then persistently writes back the selection it just used as the thread's new durable record (Orchestrator.ts:5268-5290), so a device whose local draft is stale doesn't just use the old provider for one send — it durably reverts the thread for everyone.
  • The same last-writer-wins semantics also hit queued runs (provider/model frozen at queue time, Orchestrator.ts:5076-5082), steering (pins the active run's model, Orchestrator.ts:4931), delegated completions (re-pin the completed run's model, EffectWorker.ts:292-295), and cron (always re-sends the task row's creation-time selection, queued, ScheduledTaskService.ts:802/825-827).

Filed all of it with the full chain, three reproductions, and a suggested fix direction here: #19376. This looks like one root cause behind #18762, #15195, and the cron half of #16833, rather than three client bugs.

Nnone239d ago
Synced from GitHub

This is a real UX issue that causes a lot of accidental model/provider handoffs for me.