Skip to content

[Bug]: Mobile has no way to switch Claude Opus to another Claude login when one account hits its limit #28872

New issue
New issue
Closed
Closed
[Bug]: Mobile has no way to switch Claude Opus to another Claude login when one account hits its limit#28872

Description

@jamesdchen
jamesdchen
opened on Nov 1, 2026

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

  1. On a T3 Code server (0.1.6, Windows x64), have Claude Code set up with a single provider instance (the default claudeAgent) signed in to Claude account A. A second Claude login (account B) is on the same machine in its own config directory (~/.claude-willy), but it isn't set up as a T3 provider instance.
  2. From the mobile app, run a thread on Claude Opus until account A hits its weekly limit. The turn fails with Claude usage limit reached. This turn is paused until the 7-day limit resets in 23h 35m. and then You've hit your weekly limit · resets 12pm (America/Los_Angeles) / Claude API rate limit reached. Try again later.
  3. Still on mobile, try to switch the thread (or the Claude provider) to account B.

Expected behavior

Mobile has some way to keep using Opus on another login without going back to the desktop. Any of these would work:

  • switch the Claude provider's login (sign out of A, sign in to B),
  • add another Claude account as its own provider instance (for example, pointing at a different CLAUDE_CONFIG_DIR), or
  • pick an already-set-up compatible Claude account in the thread's model picker, the way web/desktop can (see [Bug]: Mobile thread picker hides compatible Codex accounts #14798 for the Codex version of this).

Actual behavior

Mobile has no way to change which Claude account Opus uses. The only Claude option is the instance that hit its limit. So the thread is stuck until the limit resets, unless I switch to a different provider altogether. Switching providers then broke the thread completely: after switching back, every turn failed with a t3-code MCP 401 (see #16565).

Impact

Blocks work completely

Version or commit

T3 Code server 0.1.6; current T3 Code mobile app (November 2026)

Environment

T3 Code mobile app connected to a Windows x64 desktop server (0.1.6). Provider: Claude Code (Claude Opus 5.5).

Workaround

Change the Claude login or add a second Claude instance from the desktop app, or switch the thread to a different provider (risky, see #16565).

Related

Activity

  1. jamesdchen
    changed the title [-][Bug]: Mobile app won't let me switch an existing Claude Opus thread to another Claude account[/-] [+][Bug]: Mobile has no way to switch Claude Opus to another Claude login when one account hits its limit[/+] on Nov 1, 2026
  2. juliusmarminge
    added
    needs more infoInitial triage showed no bug. Awaiting more info
    on Nov 1, 2026

  3. juliusmarminge commented on Nov 1, 2026

    @juliusmarminge
    juliusmarminge
    on Nov 1, 2026 – with GitCafe Production
    Member

    I couldn't reproduce this on current main (d897d3f), using the Android mobile app against a Linux server. The server had two Claude Code instances, Claude A and Claude B, each with its own CLAUDE_CONFIG_DIR. I tried three cases:

    1. A thread with one completed turn on Claude A · Opus 5.5. The mobile model picker listed Claude B. I picked Claude B · Opus 5.5 and sent a message. The thread showed "Context handoff CA Opus 5.5 → CB Opus 5.5" and Claude B replied.
    2. A thread whose first turn hit a weekly limit (a 429 with anthropic-ratelimit-unified-status: rejected, so the thread showed "Usage limit reached"). The mobile picker still listed Claude B, and switching to Claude B · Opus continued the thread.
    3. After restarting the server, so the thread had no live Claude session, the picker still listed every Claude instance.

    Web listed the same instances in all three cases.

    To narrow it down, could you share:

    • The mobile app version (Settings → About) and the version of the Windows desktop app it connects to.
    • How Claude A and Claude B are set up: does each use its own CLAUDE_CONFIG_DIR path, and are both enabled for this project?
    • A screenshot of the mobile Thread settings picker for that thread, scrolled through the provider groups, so we can see which groups it shows.

  4. jamesdchen commented on Nov 1, 2026

    @jamesdchen
    jamesdchen
    on Nov 1, 2026
    Author

    Sorry for the confusion — your triage caught an error in the original wording of this issue before I edited it 7 minutes after filing:

    1. Why our setups differed (Claude A / Claude B):
      The first draft of this issue (filed by an agent at 20:30:24Z, before I updated the description at 20:37:23Z) wrongly assumed two claudeAgent provider instances were already configured in settings.json. I do have two CLAUDE_CONFIG_DIR instances configured on a separate Linux server, which works as you described, but on the Windows desktop server where this happened, only the single default claudeAgent instance was configured (a second login directory ~/.claude-<alt> existed on disk from cc-switch, not yet added to providerInstances).
      So the existing-thread model picker showing only one Claude group on that server is expected — there is no picker filtering bug when two instances are configured.

    2. Versions & setup details requested:

      • Windows desktop / server: 0.1.6 (Windows 11 x64)
      • Mobile app: Android (okhttp/5.4.0 in auth_sessions; client_app_version is null on the server side, can grab the exact Settings → About build from the phone if still helpful)
      • Windows settings.json providerInstances: only antigravity, grok, acpRegistry_kimi_cli, and codex (disabled), plus the implicit default claudeAgent.

    3. What actually blocked switching logins from mobile:
      Right after claudeAgent hit the weekly limit while away from the PC, I opened Settings → Providers on Android (SettingsProviderAccountsRouteScreen.tsx) to either switch the Claude login or add the second Claude account:

      • Claude is absent from mobile Settings → Providers: SettingsProviderAccountsRouteScreen.tsx filters providers through canManageProvider (provider.setup?.canAuthenticate || (provider.driver === "acpRegistry" && provider.installed)). Because ClaudeDriver / ClaudeProvider doesn't expose an in-app ProviderAuthController (setup.canAuthenticate is unset), Claude doesn't appear on that screen at all — unlike Codex, Antigravity, Grok, and ACP Registry providers, there is no Change account or Sign out action for Claude.
      • No way to add a second Claude instance from mobile: AddProviderInstanceDialog (configuring a second instance with its own CLAUDE_CONFIG_DIR) only exists in apps/web, not apps/mobile.

    So if you hit a Claude usage limit while on mobile and haven't pre-created a second CLAUDE_CONFIG_DIR provider instance from desktop/web ahead of time, there's no way from mobile to either re-authenticate claudeAgent to another Claude login or add the second instance. (Happy for this to be reclassified/moved to Discussions as a feature gap around mobile Claude auth / instance management rather than a picker bug!)

  5. juliusmarminge
    removed
    needs more infoInitial triage showed no bug. Awaiting more info
    on Nov 1, 2026

  6. juliusmarminge commented on Nov 9, 2026

    @juliusmarminge
    juliusmarminge
    on Nov 9, 2026 – with GitCafe Production
    Member

    Thanks for the detailed report! #28928 added mobile configuration of a separate signed-in Claude account in e4e3657344, so it can be selected from the thread picker.

  7. juliusmarminge
    closed this as completedon Nov 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions