Repository navigation
Claude account switch does not reach a running session; two panes in one worktree can run on two accounts #19900
Description
Operating system
Linux (Ubuntu 24.04.4 LTS, kernel 7.0.14-15-pve, LXC container). Managed auth runtime: host.
Orca version
1.4.197 — with Claude Code 2.1.267
Details
Summary. Switching the managed Claude account has no effect on a Claude Code session that is already running. The running pane keeps the previous account until the process is restarted or the user logs in again. This was reliable on my previous host and stopped after I moved to a new one.
This appears to contradict #19589, which states that selectClaude() "takes effect without asking the user to restart anything" and that only Codex needs a restart. On this host, Claude behaves the same as Codex: the account is bound when the process starts.
It may also be a regression of #12098 ("the terminals stay on the old account"), which was closed as completed on 2026-09-04.
What I observe.
orca account listreports three managed Claude accounts, allauthMethod: subscription-oauth,managedAuthRuntime: host.- Switching the active account rewrites
~/.claude/.credentials.jsonin place. That file holds exactly oneclaudeAiOauthrecord, so the swap overwrites the previous account's token. ~/.claudeis a real directory, not a per-account symlink, andCLAUDE_CONFIG_DIRis unset. So every pane on this host shares one credential file. This is the in-place swap mechanism described in [Feature]: Per-pane managed accounts for Claude (Codex parity) instead of in-place credential swapping of the default CLAUDE_CONFIG_DIR #14254.- Codex has
~/.config/orca/codex-pane-accounts.json. There is no Claude equivalent, so nothing binds an account to a pane. - A Claude Code process reads the credential at start. Claude Code does not document any re-read of
~/.claude/.credentials.jsonwhile a session runs, so a swap after start is invisible to that process until it exits.
Observed side effect: two panes in one worktree on two different accounts.
On this host the credential file was rewritten at 14:21 UTC. In one worktree two Claude processes were alive at that moment:
| PID | Started | TTY | Credential state it holds |
|---|---|---|---|
| 1734936 | 12:22 | pts/27 | the account active before 14:21 |
| 1962703 | 14:26 | pts/3 | the account active after 14:21 |
The two panes therefore bill to two different subscriptions with no indication in either one. ~/.claude.json still records the oauthAccount of a third account, so the stored account record and the live token disagree as well.
The second process here is itself a duplicate resume of the same session, which is #13716 / #18702. The two defects combine badly: a duplicated pane can silently run on a different account from its twin.
Expected behaviour.
Either of these would be acceptable:
- An account switch applies to running Claude panes, as Codex account switch cannot move running panes, and 'Restart Sessions' destroys the conversation — no Claude equivalent #19589 says it already does.
- Or Orca states plainly that running panes keep the old account, and offers the same explicit path Codex has, without destroying the conversation. A resume of the same session is enough, because the session transcript survives.
What does not work as a workaround. Claude Code stores one account at a time and has no in-session account switch. /logout ends the session. So the user has no way to move a running pane to the new account from inside Claude Code.
Reproduction. Add two managed Claude accounts. Open a worktree and start a session. Switch the active Claude account in Orca. Watch the running pane: it continues on the first account. Compare stat -c %y ~/.claude/.credentials.json with the start time of the claude process.
Activity
AmethystLiang commentedon Sep 11, 2026
thanks for reporting. looking into it
adifsgaid commentedon Oct 13, 2026
Ran into this from the other side while working on #28044, which switches accounts automatically before a usage limit. Same wall there: a switch, by hand or automatic, only reaches the next
claudeyou start.+1 to option 2 from @erwiol. Orca already has most of the pieces. It builds
claude --resume <session_id>for a pane (agent-resume-argv.ts, used to wake sleeping agents),claudereads the selected account when it starts, and the account folders share their history. So a pane resumed after a switch should come back with the same conversation on the new account. Orca could do that for every Claude pane still on the old account, behind a "Move N sessions" button like Codex has, or on its own for panes that are idle. A pane in the middle of a turn would wait until it finishes.@AmethystLiang are you already on this? If not, I'm happy to send a PR once #28044 has had a look.
Tauri-EPO commentedon Oct 16, 2026
Retested on Orca 1.4.227, Claude Code 2.1.301, Windows 11 (host runtime, managed subscription accounts).
The mechanism has changed since this was filed: with per-account folders (#26801), each
claudegets its account'sCLAUDE_CONFIG_DIRwhen it starts, and Orca no longer rewrites~/.claude/.credentials.json. The symptom is the same, but it's now by design:claude-profiles/selected-host) and the running session'sCLAUDE_CONFIG_DIR: the pointer moved to the new account and the session kept the old one.claudestarted in a new tab after the switch came up on the newly selected account (/status).So the first half of option 2 is in place: the switch toast now says "Running sessions keep their account." What's still missing is the second half, a way to move a running pane to the new account without losing the conversation, like Codex's restart prompt (which resumes the thread since #25485). As @adifsgaid noted above,
claude --resume <session_id>and the shared history across account folders seem to cover most of it.One interaction to keep in mind: if #28684 lands, panes kept on an account would need to be left out of that prompt.
joefour commentedon Oct 16, 2026
Confirming on Orca 1.4.227, Claude Code 2.1.301, macOS. Until Orca does this, I'm running the approach above as a local UserPromptSubmit hook, and it works. On the first prompt after a switch it blocks the prompt, stops that claude, types claude --resume with the session id into the pane through orca terminal send (Orca's zsh wrapper then picks the new account), and sends the prompt again. Same conversation, new account, a few seconds.
Things we hit that a built-in version would also need to handle:
• A prompt blocked by a hook goes back into the composer, so typing /exit into the pane gets appended to it. Stopping the process works.
• Restarting kills the session's background shells and subagents. We ask once before restarting when shells are running.
• Pasted images can't be re-sent as terminal input. We type the text back unsent, and the user attaches the image again.
• The resume has to keep the pane's original launch flags. Panes that scripts start with flags like --settings or --mcp-config lose them if they are resumed with a fixed command.
• tmux teammate panes share the outer pane's ORCA_TERMINAL_HANDLE, so input meant for one pane lands in another.
+1 for the "Move N sessions" button, with an automatic option for idle panes.
adifsgaid commentedon Oct 16, 2026
Opened #29802 for this.
After a switch, the Claude account menu now says how many sessions are still on the old account, with a Move Sessions button like the Codex restart prompt. Each session reopens in its own pane with
claude --resume <id>once its turn is over. There's also an opt-in setting that does it without asking for sessions sitting idle in a tab you're not looking at.@joefour your list shaped most of it, thanks:
@Tauri-EPO agreed on the kept panes. #28684 isn't in yet, so there's nothing to skip today. Once it lands I'll make the move leave a kept pane where it is.
@hyeonjong-ai you mentioned running 6 to 8 sessions at once on #20512. If you get a chance to try the branch, I'd like to hear how it holds up with that many.
adifsgaid commentedon Oct 17, 2026
Quick update: I ran #29802 last night with two real accounts, not just the e2e stub.
claude --resume, same session id, answered from the earlier turn, and/statusshowed B's login.One thing worth knowing: moving onto an account that's out of credits just lands you on Claude's own limit prompt, so the switch itself should pick an account with room left. That part is #28044.
adifsgaid commentedon Oct 17, 2026
#29898 landed on main and covers this. After a switch, Orca offers to restart the Claude sessions still on the old account with
--resume, and Settings › Accounts has Ask / Always restart / Never restart. I closed #29802 in its favor.asunghong commentedon Oct 18, 2026
Still broken on Orca 1.4.229, Claude Code 2.1.302, macOS 26.5, zsh 5.9, and there is a worse case that this issue does not cover yet: terminals opened before the update ignore the account switch entirely.
Summary
Since per-account config folders (#26801, v1.4.225), an account switch only reaches a
claudestarted afterwards. Before 1.4.225, a running session followed the switch shortly after. Now it keeps the old account.Worse: a terminal that was already open when Orca updated does not have Orca's
claudeshell function. Any Claude started in that tab runs on the System default login, whatever account is selected./exitthenclaude --resumedoes not help. Only a new terminal does. The only hint is one banner, which is easy to miss. I only found the cause withtype claude.Steps to reproduce
/exit, thenclaude --resume, then/status: it shows the System default login, not B.type claudein that tab: it resolves to the binary, not Orca's function.claude: it comes up on B.Expected vs actual
Impact
Requests
adifsgaid commentedon Oct 18, 2026
@asunghong thanks for the detailed write-up, the pre-update tab case is a nasty one and
type claudeis a good find.Two things that should help once they're in a release:
claude --resumethere, so the new shell has Orca'sclaudefunction and the session comes back on the selected account. That should cover your step 4 as well, though I haven't tried it on a tab opened before 1.4.225.