[Bug]: Claude account switch skips running panes: only previous-account panes are candidates, and after an update none of those restarted #33551

Operating system

macOS

Orca version

1.4.240 (auto-updated from 1.4.237 a few minutes before the switches below)

Details

Summary

With When you switch accounts while Claude is running set to Always restart (claudeAccountSwitchRunningSessions: "restart"), two account switches in a row restarted 1 Claude terminal pane. 16 other panes stayed on an account that had reached its weekly limit, so every prompt in them returned "You've hit your weekly limit". The status bar showed the newly selected account with free usage, so the status bar and the running sessions disagreed, and no message said that panes were skipped.

There are two separate problems:

1. By design, a switch only considers panes that it can tie to the account selected immediately before the switch. A pane that runs on an earlier account is never offered, even with Always restart.
2. Right after the app updated, a switch away from the panes' own account also restarted none of them, although 11 of the 16 had an idle Claude status that pointed at that account.

What happened

One local host, terminal panes only. Orca started every Claude process (no hand-started claude, no tmux).

1. 16 Claude panes ran on Account A. Each claude process has CLAUDE_CONFIG_DIR=<Orca user data>/claude-profiles/<A>/home. Orca 1.4.237 had started or resumed them one to two days earlier, several of them through its own restart-on-switch. A then reached its weekly limit.
2. Orca auto-updated from 1.4.237 to 1.4.240 and relaunched. The 16 panes kept running in the previous version's terminal host. The process tree shows each claude under that host. New panes start in the new host.
3. About 5 minutes later, I signed in again to Account B and selected it. No pane restarted. daemon.log shows no kill and no spawn in this window.
4. A new Claude pane started on B, in the new terminal host.
5. I selected Account C. Orca restarted only the B pane from step 4 ("Restarting 1 Claude session"). The 16 panes from step 1 stayed on A. After this step, a prompt in an A pane still returned A's weekly-limit error.

Checks after step 5:

• ps eww for each of the 16 claude processes: CLAUDE_CONFIG_DIR is still A's folder, while claude-profiles/selected-host names C.
• In orca worktree ps --json, 11 of the 16 panes had an idle (done) agent row. Their persisted hook status (agent-hooks/last-status.json) has a transcriptPath under A's folder. The other 5 panes had no agent row.

Cause, as far as I can trace it (v1.4.240 source)

1. Only panes on the outgoing account are candidates. handleRunningClaudeSessionsAfterSwitch passes the account that was selected just before the switch as fromAccountId (claude-account-switch-sessions.ts L101, L121-L128). findMovableClaudeSessions drops every pane whose account is not exactly fromAccountId (claude-session-account-move.ts L195-L198). After A → B → C, the A panes can move only on a switch away from A. This fully explains step 5.

2. The pane's account is inferred from its hook status, not recorded at launch. resolveClaudeSessionAccountId reads the account from providerSession.transcriptPath (L81-L102), and localClaudePanesInLane skips any pane that has no agentStatusByPaneKey entry (L145-L148). A pane without a status cannot be moved by any switch, even when it runs on the outgoing account. The 5 panes with no agent row in step 3 are likely this case.

3. Not explained: in step 3, the 11 panes that had an idle status pointing at A were also skipped. What all 16 have in common is that they ran in the previous version's terminal host, while the one pane that did restart ran in the new host. The scan logs nothing, so I could not tell which check dropped them. Candidates are the renderer's ptyIdsByTabId binding after the relaunch (L134-L144), inspectRuntimeTerminalProcess against the old host, and isClaudeInForeground (L222-L230).

4. The skip is silent. When the scan finds nothing, handleRunningClaudeSessionsAfterSwitch returns 'show-confirmation' (L134-L136). The status-bar menu ignores that result (ClaudeSwitcherMenu.tsx L193-L200), so a status-bar switch shows no message. The Settings path shows "Running sessions keep their account", which does not say which panes were skipped or why.

Codex already handles this case: listStaleCodexPanes compares each pane's recorded launch account with the active account, so every Codex pane that is not on the active account is flagged, whatever was selected before (codex-stale-pane-accounts.ts L15-L35). Claude panes have no such record.

Expected

After a switch, every running Claude terminal pane that is not on the newly selected account is restarted with claude --resume <session id> (Always restart) or listed in the Ask dialog. This includes panes started under an earlier account or System default, panes with no hook status, and panes still in the previous version's terminal host after an update. A pane that cannot be moved is listed with the reason.

Suggested fix

1. Record each Claude pane's launch account when Orca starts Claude in it, as codex-pane-account-registry does for Codex. Orca already chooses the account at spawn (CLAUDE_CONFIG_DIR / ORCA_CLAUDE_INJECTED_CONFIG_DIR, and the claude shell function reads selected-host at each launch).
2. In the switch handler, select every Claude pane whose recorded account is not the new account (a Claude version of listStaleCodexPanes), instead of accountId === fromAccountId. Leave out panes that are kept on their account (feat(accounts): keep a Claude or Codex agent on its account #28684).
3. Do not require a live hook status. Use the recorded launch account, a foreground-process check that also works for panes in an older terminal host, and a session id from the recorded provider session or from Claude's <CLAUDE_CONFIG_DIR>/sessions/<pid>.json.
4. Name the skipped panes in the toast or dialog, and log one line per skipped pane with the check that dropped it.

Steps to reproduce (problem 1)

1. Add three Claude accounts A, B and C. Set the switch setting to Ask.
2. Select A. Start a Claude pane P1 and send one prompt.
3. Select B. In the dialog, choose Keep as is. P1 stays on A.
4. Start a Claude pane P2 on B and send one prompt. Set the switch setting to Always restart.
5. Select C. Only P2 restarts. P1 stays on A, and no message mentions it.

I have not reproduced problem 2 in isolation. It happened on the first switch after an auto-update, with all affected panes still in the previous version's terminal host.

Workaround

In each stuck pane, run /exit, then claude --resume <session id> in the same pane. Orca's claude shell function starts it on the selected account.

Do not use /login inside the pane. It writes the new login into the pane's account folder, so the Orca account entry that owns that folder now holds a different login. Afterwards, Orca listed two account entries with the same email.

Related

• [Bug]: Account switch restarts only some running Claude panes; panes without a managed CLAUDE_CONFIG_DIR stay on the old account #31902: same symptom. Its System-default pane is a case of problem 1, because that pane's account is null, not fromAccountId.
• [Bug]: Regression: switching Claude accounts no longer updates existing Claude Code sessions #29870: a comment from 2026-10-24 reports 6 of 9 panes left on the old account.
• Claude account switch does not reach a running session; two panes in one worktree can run on two accounts #19900, and feat(accounts): offer to restart running Claude sessions on the new account after a switch #29898, which added restart-on-switch.
• feat(accounts): keep a Claude or Codex agent on its account #28684: keep a pane on its account. The fix above should leave those panes alone.
• On 1.4.237, one switch on the same machine restarted 7 of 14 running Claude panes. This is possibly the same cause. I did not check it at code level.