Adding a second claude account broken

[wolph]

Most of the time when I click "Add account" it just gets stuck on this and does nothing:

Sometimes after a fresh restart it does open the browser, but I end up with the same result of waiting for the browser.

For codex it works fine.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 22, 2026, 9:05 PM ET / 01:05 UTC.

Summary
Keep open: current main still routes Claude Add/Switch Account through the ambient claude /login flow and the documented Claude multi-account path is manual token accounts, so the reported second-account browser flow is not fixed or clearly implemented on main.

Reproducibility: no. live repro was run. Source inspection does identify the current path: Claude Add/Switch Account enters the waiting-browser state while claude /login waits for CLI confirmation and does not create a stored second Claude account.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
The bug is credible, but an automated fix should wait for maintainer direction because the likely fixes touch Claude auth UX, credential discovery, and privacy-sensitive Keychain behavior.

Review details

Best possible solution:

Decide the intended Claude multi-account UX, then either make Add/Switch Account create and select siloed Claude accounts through existing Keychain gates or guide users clearly to the manual token-account flow.

Do we have a high-confidence way to reproduce the issue?

No live repro was run. Source inspection does identify the current path: Claude Add/Switch Account enters the waiting-browser state while claude /login waits for CLI confirmation and does not create a stored second Claude account.

Is this the best way to solve the issue?

Unclear. A timeout or clearer error would reduce the stuck state, but true second-account parity with Codex requires a maintainer decision around Claude account discovery, stored credentials, and privacy gates.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live Claude/browser/Keychain reproduction was run because repository policy requires explicit request for validation that can prompt for credentials.
• The desired end state needs maintainer judgment: fix the ambient Claude login timeout/error path, add managed Claude account discovery, or relabel the UI toward the existing manual token-account workflow.
• Open PR [codex] Refine Claude stacked account menu #1707 overlaps with Claude multi-account discovery but is not a safe canonical fix while it remains draft with proof and credential-boundary blockers.

Codex review notes: model internal, reasoning high; reviewed against ef8007fc16ce.

Label changes

Label changes:

• add P2: The report affects a real provider account-add/login workflow, but the blast radius is scoped to Claude multi-account setup.
• add impact:auth-provider: The issue is about Claude provider authentication and account selection behavior.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The report affects a real provider account-add/login workflow, but the blast radius is scoped to Claude multi-account setup.
• impact:auth-provider: The issue is about Claude provider authentication and account selection behavior.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance against live provider, browser-cookie, and Keychain-prompt validation shaped this as a source-only review. (AGENTS.md:1, ef8007fc16ce)
• Vision fit: VISION.md keeps provider limits, provider coverage, and bounded bug fixes in scope, but calls provider auth, privacy, and behavior changes sign-off sensitive. (VISION.md:1, ef8007fc16ce)
• Claude menu login path: The shared account section exposes Add Account/Switch Account for providers with login flow support, and Claude declares login-flow support. (Sources/CodexBar/MenuDescriptor.swift:604, ef8007fc16ce)
• Claude login does not add a token account: The Claude login flow runs ClaudeLoginRunner, then on success enables Claude and selects OAuth; it does not create or select a stored Claude token account. (Sources/CodexBar/Providers/Claude/ClaudeLoginFlow.swift:14, ef8007fc16ce)
• Waiting-browser source path: The Claude runner switches to the waiting-browser phase when a URL is detected and keeps the PTY running until CLI success text or timeout, matching the reported waiting state. (Sources/CodexBar/ClaudeLoginRunner.swift:67, ef8007fc16ce)
• Documented multi-account path: Claude docs say multi-account manual tokens are added through tokenAccounts with Claude cookies set to Manual, while token accounts accept sessionKey cookies, OAuth tokens, or Admin API keys. (docs/claude.md:88, ef8007fc16ce)

Likely related people:

• steipete: Git history and blame tie this handle to Claude login behavior, shared provider/token-account settings, and recent token-account menu/data fixes. (role: recent area contributor and feature owner; confidence: high; commits: 4373855c6a1a, 8f676d8f88a6, 6eb3b7e8307b; files: Sources/CodexBar/ClaudeLoginRunner.swift, Sources/CodexBar/Providers/Claude/ClaudeLoginFlow.swift, Sources/CodexBar/PreferencesProvidersPane.swift)
• ratulsarna: The reporter compares Claude with Codex; history shows this contributor introduced the managed Codex multi-account path that behaves differently from Claude's ambient login flow. (role: adjacent Codex multi-account contributor; confidence: medium; commits: dd200dac317d; files: Sources/CodexBar/ManagedCodexAccountService.swift, Sources/CodexBar/ManagedCodexAccountCoordinator.swift, Sources/CodexBar/PreferencesCodexAccountsSection.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[wolph]

To reproduce:

1. Open CodexBar with one Claude account already signed in.
2. Open account/provider management for Claude.
3. Click "Add account" (second Claude account).
4. Observe: UI sticks on the "waiting for browser" state; no browser tab opens; OAuth never completes.

Intermittent variant:

• Fully quit CodexBar, relaunch, repeat steps 2–3. Browser opens this time, but flow still hangs on "waiting for the browser" and no second account is added.

Control case (works): same flow for a second Codex account completes normally. Only the Claude provider path fails.

Extra info:

• CodexBar version: 0.37.2 (92)
• macOS version: Version 26.5 (25F71)
• Default browser: Google Chrome 149.0.7827.116

[steipete]

Post-merge proof correction for #1811:

• Reviewed head: d467ef27cc3fb0a245380f617a13bf2e64f97d0c.
• Local proof before merge: focused Claude login/menu tests passed, make check passed, the preserved full suite passed 44/44 shards, packaged signing verification passed, and synthetic packaged UI/PTY proof used no real credentials or provider calls.
• At merge time, GitHub showed five checks green but the four exact-head macOS shards were still queued. Therefore exact-head CI was not all green at merge time; the merge happened too early.

The original exact-head run is still being monitored: https://github.com/steipete/CodexBar/actions/runs/28504181327. If any macOS shard fails, I will reproduce and fix forward from current main in a new reviewed PR, then wait for its full exact-head CI before landing.

[wolph]

Thanks for the fix @steipete!

[steipete]

Post-merge CI follow-up:

• The original exact-head run later completed successfully: https://github.com/steipete/CodexBar/actions/runs/28504181327
• Verified head: d467ef27cc3fb0a245380f617a13bf2e64f97d0c.
• All four macOS shards passed, as did Linux x64/ARM64, lint, changes, and the aggregate lint-build-test gate.

This does not change the merge-time record above: at merge time five checks were green and all four macOS shards were still queued, so exact-head CI was not all green then. The preserved local full-suite result was 44/44 shards. Because the original exact-head run ultimately passed, no forward-fix PR was needed.