Repository navigation
[Bug]: Mobile model picker: Opus 5.5 under a second Claude instance runs on the default Claude instance #36126
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/mobile
Steps to reproduce
- On a server with two Claude Code provider instances, the default
claudeAgent("Claude") and a second one with its ownCLAUDE_CONFIG_DIR("Claude Pulse"), both offering Claude Opus 5.5. - Open an existing thread in the mobile app (iPad, split view). The thread was on Codex GPT-6.1 Terra.
- Open Thread settings, scroll to the Claude Pulse group and pick Claude Opus 5.5, then confirm with the check button.
- Send a message.
Expected behavior
The thread runs on Claude Pulse · Opus 5.5, as the same pick does on web and desktop.
Actual behavior
The thread switches to Claude Opus 5.5 on the default Claude instance instead. The model is right, the provider instance is wrong. In our case the default Claude account had already hit its usage limit, so the turn failed with "Claude API rate limit reached. Try again later." even though Claude Pulse was the account picked. It only happens on mobile; the same pick from web/desktop lands on Claude Pulse.
The picker in the screenshot lists both groups separately, each with its own "Claude Opus 5.5 · Default" row (Claude Pulse's Opus and Fable are starred favorites).
Reading main (7903b48), the sheet itself looks instance-aware: ThreadSettingsSheet.tsx passes option.selection (with instanceId) to selectThreadModel, which keeps a cross-instance pick as a draft until the next message, and draftModelPickMatchesThread compares instanceId. So the instance is probably lost after the pick: when the draft pick is sent with the message, or when the server resolves a cross-instance switch to a model of the same driver.
Impact
Blocks work: with two Claude accounts, mobile cannot move a thread onto the second account, which is the reason to have it.
Version or commit
Server 0.1.3 (macOS); current iOS/iPadOS T3 Code app (November 2026)
Environment
iPad mobile app connected to a macOS desktop server. Providers: Codex, Claude (claudeAgent), Claude Pulse (second Claude Code instance).
Workaround
Pick the Claude Pulse model from web or desktop.
Related
- [Bug]: Mobile has no way to switch Claude Opus to another Claude login when one account hits its limit #28872: mobile had no way to switch to another Claude login (closed; that setup had only one Claude instance).
- fix(server,mobile): a model pick applies to the message it was sent with #25587: mobile model pick applies to the message it was sent with (open PR, may touch the same path).
Activity
FormalSnake commentedon Nov 13, 2026
NOTE: Claude filed this bug for me after searching for open PR's and issues, it is a bug i found myself after using the app a while, which hasn't been fixed after a few updates
shivamhwp commentedon Nov 13, 2026
Thanks for the detail. Two things changed after the build in this report.
claude-personal, and the default Claude instance stays unused.We haven't confirmed it on a device, and I can't see your app build. Could you check on a current build and tell us:
If it no longer happens on the current build, a "works now" answer is enough.
— Claude, T3 issue watch
juliusmarminge commentedon Nov 13, 2026
@FormalSnake Which mobile app version does Settings > About show, and does the pick still land on the default Claude after updating the app to the latest build? (On current main, and with a v0.1.3 server and the current app, the same steps run on Claude Pulse; the mobile pick-then-send path was rewritten by #31739 after 0.1.3.)
FormalSnake commentedon Nov 13, 2026
It is 2.3.0 right now, with server 0.1.3 (MacOS)
This bug doesnt happen on my iPhone which is also on 2.3.0, both appear to use different dialogs in this version.
Do you need me to install a custom build on my device?
juliusmarminge commentedon Nov 13, 2026
@FormalSnake Could you update the iPad app from the App Store (the iPhone already works) and try the Claude Pulse pick again? If it still lands on the default Claude, please send the iPad's build number from Settings > About: it's the number after 2.3.0, which is shown on every build. That tells us whether the iPad build includes the fix for this path (#31739).
FormalSnake commentedon Nov 13, 2026
Follow-up: on iPad 2.3.0 (248), in a new thread defaulting to Claude Opus, tapping Claude Pulse Opus twice left Claude selected. Selecting a Codex model first, then Pulse Opus, worked. A second new draft worked on the first tap. When Pulse was shown in the composer, the first run used Claude Pulse. This appears intermittent and may be a selection failure before sending.
shivamhwp commentedon Nov 13, 2026
We tried to reproduce this on an iPad Pro 13-inch (M5) simulator on iOS 27.0, on current main (7903b48), with two Claude instances, the default one and Claude Pulse, both offering Claude Opus 5.5. The turn goes to Claude Pulse each time, the default instance gets nothing, and the default is rate limited for the run. Three variants:
Claude Pulse was used every time. So on main we can't reproduce what you saw on iPad 2.3.0 (248).
What would help: does it still happen after you fully quit and reopen the app, with the same thread? And did that thread or draft already have a model picked before you tried Claude Pulse? If it does, a screen recording of the picker, the confirm, and the send would show us the state we're missing.
— Claude, T3 issue watch
FormalSnake commentedon Nov 15, 2026
When I start the thread, the default claude account is selected with my default opus 5.5
Upon switching to opus 5.5 on Claude Pulse, there's a chance it doesn't switch to the secondary account.
This is hard to reproduce for me too for some reason, but I have experienced it a few times.
FormalSnake commentedon Nov 15, 2026
What I can say is that my T3 server is often at a high CPU load, and maybe the packet for switching models gets lost occasionally, im not sure
shivamhwp commentedon Nov 15, 2026
We tested the mid-run case on an iPad simulator, on current main (7903b48), with the default Claude instance held for two minutes:
Result: the send is refused with "Claude-pulse cannot redirect an active run. Stop it first, then send the message." The text stays in the composer, and nothing goes to the default account. A pick made while nothing is running routed to Claude Pulse each time, as in the earlier comment.
So on main the mid-run switch does not fail silently. It fails with that message. Did you see that message, or did the send look normal and the reply come from Claude? If it looked normal, the server log lines from that send would show which instance took the turn. Please send them, and include the thread's provider lines from around that time.
— Claude, T3 issue watch