Repository navigation
[Feature]: Per-worktree account pinning — run different Claude/Codex accounts concurrently #9496
Description
Summary
Multi-account support for Claude Code (and Codex) currently works as a global hot-swap: exactly one account is active at a time, and swapping rewrites the active credential pointer for everything. I'd love to be able to pin an account to a worktree (or pick one per agent session at launch) so that different worktrees can run under different accounts concurrently.
Current behavior
Per the hot-swap docs:
- Swapping rewrites the active credential pointer; any new session launched afterwards uses the new account.
- Sessions already running keep their original account until restarted.
- A restarted session picks up whichever account is active at restart time.
- Usage readouts in the status bar follow the currently-active account only.
So the only way to get two accounts running side by side today is a fragile sequencing trick (launch sessions on account A → swap to B → launch more sessions), and it silently breaks the moment any session restarts.
Use case
- Keep work repos on a work account and personal/OSS repos on a personal account — billing separation and IP hygiene — while both are open in the same Orca window.
- Deliberately spread parallel agents across accounts to manage rate limits, instead of relying on launch order.
Proposed solution
- An optional account pin at the worktree level, and/or a per-session account picker in the agent launch flow.
- Pinned sessions always launch and restart with their pinned account; unpinned sessions follow the global active account, same as today.
- Usage / rate-limit tracking reads the pinned account's state for those sessions.
Possible implementation
Claude Code already supports fully isolated profiles via CLAUDE_CONFIG_DIR — each directory holds its own independent credentials, so concurrent multi-account works at the CLI level today. Orca could manage one config dir per labeled account (e.g. ~/.orca/claude-profiles/<label>) and launch pinned sessions with that env var set. Codex looks analogous via CODEX_HOME.
Workaround today
Registering a custom CLI agent with CLAUDE_CONFIG_DIR=~/.claude-b claude works for launching a second account, but Orca's usage tracking and account-aware session start still read the default ~/.claude, so the second account's usage/limits aren't reflected — and it doesn't participate in the hot-swap or restart flows.
Thanks for the great tool — happy to add details or test a build.
Activity
[-][Feature Request] Per-worktree account pinning — run different Claude/Codex accounts concurrently[/-][+][Feature]: Per-worktree account pinning — run different Claude/Codex accounts concurrently[/+]hworknet commentedon Oct 8, 2026
+1. My use case: separate Codex accounts per client project (each client pays for its own account), so work for client A must never run on client B's account. Today the only option is switching the account globally, which flips every open worktree at once. A per-project default with a per-worktree override (as proposed in #7782) would solve it.
jorgej-ramos commentedon Oct 8, 2026
+1
I use up to three Claude accounts and up to two Codex for different clients, and none of them should cross to another client. This feature can be the killer one for complex workspaces. Actually I use profiles on iTerm2 to manage this, and it feels a bit ugly.
I would also like to suggest that subscriptions could be assigned by repository groups.
AmethystLiang commentedon Oct 8, 2026
Thanks for the feedback. Will look into it
pawel-kotowski commentedon Oct 9, 2026
Related work that may help here:
orca account select#26870 addsorca account select --agent claude|codex --account <id|email|system>, so scripts and agents can choose the subscription beforeorca worktree create --agent claude. Tracking issue: [Feature]: run any Claude/Codex subscription on any workspace, from the CLI #26875.--accountflag onworktree create.nwparker commentedon Oct 18, 2026
Consolidating #29808 here: the request is to run multiple Claude or Codex sessions at the same time, logged into different accounts. This matches the existing concurrent per-worktree/per-session account requirement. The feature remains open; closing that duplicate does not claim a complete account-selection/pinning flow has shipped or invalidate related work such as #28684.
TerrysPOV commentedon Oct 19, 2026
+1, with a use case from agent orchestration that makes per-launch selection more than a convenience.
I run my development cycle through Orca supervised workers: a Claude coordinator dispatches Codex workers with
orca orchestration worker-start --agent codex …. I have two Codex seats on one Business workspace, both added as managed accounts in the Orca UI. When one seat hits its usage limit mid-task, the worker stalls. The coordinator has no supported way to relaunch that worker on the other seat, because the account switch is global and neitherorca agent launchnororchestration worker-starttakes an account. In practice the work waits until I notice and switch accounts by hand.What would solve it:
--account <id|label>flag onorca agent launchandorca orchestration worker-start(Codex and Claude), applying only to that launch; and/oraccounts.selectCodexruntime RPC, although per-launch is what concurrent workers actually need, and a global switch races with them.Workaround I'm using meanwhile, in case it helps others: each managed account already lives in its own home under
<Orca userData>/codex-accounts/<accountId>/home, soorca terminal create --command "CODEX_HOME=<that home> codex …"followed byworker-start --terminal <handle>runs a supervised worker on a chosen seat, with no re-login. Two caveats:hooks.json, hook links and trust state that the active one has.