Repository navigation
[Feature]: Opt-in "shared login" mode so an account switch applies to running Claude Code and Codex sessions (the pre-v1.4.225 behaviour) #29999
Description
Problem or use case
Orca version
v1.4.227 (latest)
Problem or use case
I use several Claude and Codex subscriptions so I can keep working when one runs out of usage.
Before per-account folders (#26801, v1.4.225 / v1.4.227), all sessions shared one login. When account A hit its limit mid-task, I switched to B in the status bar and the running session in the same tab simply continued on B. No restart, no new tab, no hand-off.
Now each account has its own isolated home, so a switch only applies to processes started afterwards. Hand Off, Session History resume and restart all exist, but they all mean leaving the running session and starting another one. For my workflow, the old behaviour was simply better: one click and keep going.
Others have hit the same thing: #19900 (account switch does not reach a running session), #23542 (after hitting the limit and switching, agents stay on the old account).
Proposed solution
Proposed solution
Keep per-account homes as the default, and add an opt-in setting, e.g. Settings → Agents → "Shared login: account switches apply to running sessions", for Claude Code and Codex:
- When on, Orca uses one shared login per agent (as before v1.4.225), and switching the account moves every running session to the new account.
- When off (default), current behaviour: isolated homes, parallel accounts per workspace ([Feature]: Per-worktree account pinning — run different Claude/Codex accounts concurrently #9496, [Feature]: run any Claude/Codex subscription on any workspace, from the CLI #26875).
Alternatives or additional context
- Hand Off / Session History resume / restart work, but each starts a new session instead of continuing the running one.
- Downgrading to v1.4.224 restores the old behaviour but loses recent fixes.
- I understand the shared mode had the expired-token problem ([Bug]: Switching the Claude account with a live Claude terminal writes the target account’s expired token into the shared credential, and every running session dies with “Login expired” #23885). In shared mode, Orca could refresh and validate the target account's token before writing it, as suggested in that issue, so a switch never kills running sessions.
Alternatives or additional context
No response
Activity
kuroda-fvr commentedon Oct 19, 2026
This is the one feature I use Orca for, and it stopped working after updating to v1.4.229 😢
My workflow: I run several Claude accounts on Windows 11. When the current account hits its limit, I switch accounts in the status bar and the running session just keeps going on the new account. That was exactly why I started using Orca.
On v1.4.229, the System default hit its limit, I switched accounts, and the status bar looked like it had switched — but the running session stayed on the System default and stopped. When I signed out of the Windows login, that session changed from "limit reached" to "please sign in", so it was clearly still using the old account.
Hand Off, resume or restarting are not a workaround for me. I run a large number of workflows inside a single session, and starting a new session means losing all of that state. I need to switch the account underneath the session while keeping that session alive.
I've gone back to v1.4.224 for now, where it works as before, but I'd love to stay up to date. Could the old behaviour (switching applies to running sessions) come back, even as an opt-in setting? Please 🙏🥺
(I'm not a native English speaker, so I used a translator. Sorry if anything reads oddly!)
RichardDBrown commentedon Oct 19, 2026
Thanks for sharing your workflow, @kuroda-fvr! It's good to know I'm not the only one relying heavily on mid-session account switching to preserve long-running session state.
In the meantime, while waiting to see if the maintainers can add an opt-in setting, I've been testing a few workarounds:
claude-swap: Allows logging out and switching accounts without having to close the running terminal session.magpie): Can forward requests via gateways, though keep in mind potential privacy risks and Anthropic's rate-limiting/ToS enforcement.That said, downgrading to
v1.4.224is still the most seamless option right now. Really hope the maintainers consider an official opt-in flag so token refresh/validation can be handled safely without killing active sessions!