[FEATURE] Command line auth browser selection for OAuth login flow (--no-browser / BROWSER env)

Open 💬 0 comments Opened Jul 3, 2026 by jonathanhart

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

### Problem

When you're logged into one Claude account in your default browser and want to authenticate a second account via claude auth
login
(or claude setup-token), the OAuth flow auto-opens the default browser — which is already signed into account #1.
Cookies collide, you end up re-authing account #1 into the CLI by accident, or you have to sign out of account #1 in the browser
first.

This hits anyone juggling multiple accounts: personal + work, team + client, primary + testing. Long-lived tokens from claude
setup-token
make this workflow otherwise clean — separate tokens can live in Keychain, be scoped per-terminal via
CLAUDE_CODE_OAUTH_TOKEN, etc. The browser step is the one friction point.

### Current behavior

claude auth login opens the OAuth URL in the default browser via open (macOS) / xdg-open (Linux). No way to redirect.

Workaround: press c at the prompt to copy the URL, paste into a private/guest window. Works, but requires catching the prompt
at the exact right moment — not scriptable, not obvious to new users.

### Requested behavior

In priority order (any one of these solves it):

  1. --no-browser flag — print the URL to stdout and skip the auto-open. Simplest, most scriptable, matches how `gh auth

login and gcloud auth login --no-launch-browser` already work.

  1. Honor BROWSER env var — Unix convention; BROWSER=firefox claude auth login opens the URL in Firefox. Low-cost,

respects existing conventions.

  1. --browser <path> flag — explicit override. Most flexible, most work.

### Use case

Multi-account users — team account + personal claude.ai subscription, agency staff managing several clients, engineers who keep
work and side-project auth separate. With per-terminal token routing (long-lived OAuth tokens loaded from Keychain into
CLAUDE_CODE_OAUTH_TOKEN), the CLI side is already clean. The browser is the only step that leaks between accounts.

### Prior art

  • gh auth login --web opens browser; gh auth login --with-token accepts token via stdin
  • gcloud auth login --no-launch-browser prints URL for manual open
  • Most OAuth-based CLIs honor BROWSER env var

Human Summary

This is a large pain, if we could parameterize from claude login which browser or persona's stored preference to use.. so while i deal with the back and forth of two terminals while i get them aliased to the right Claude API keys.

This would likely be a parameter in claude CLI that lets me choose some preference of browser, so i can wrap my own scripts with what keys are returned after Oauth and route them.

The main goal is to type claude-me, or claude-work, and every token gets billed to the right destination. I don't mind running different claudes for each. I gave up on one claude to rule them all but that's ok

Proposed Solution

Ideally:

a parameter in claude (optional) goes something like "-browser chrome" or "-browser firefox", and it opens that browser if exists and has my cookie auth

ill deal with the fact i need one account's claude auth in chrome but the other in firefox. it's an easy stop gap imo.

then i just instruct claude to create launch scripts where if it needs to log in it knows from prompts which browser i intend, and i just re-auth via the browser tied to that claude account.

Alternative Solutions

this whole browser based auth solution is kinda annoying to begin with. if there's a more permanent and sophisticated solution it is not advertised well not even in the models' own understanding.

it'd be nice for it all to be seamless. we have different claude accounts for different purposes and claude cli should just know where to go and which account to charge for its thinking.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I have 2 separate Claude accounts but one prompt. I want to create two agents that are tied to individual accounts. Silo'd so no one agent can use the other agent's account tokens.

I realize by wrapping claude in a script that re-auths to the appropriate account (gizmo vs spike, for instance) they bash scripts i already made.

I run into where it becomes entirely problematic because a default browser does not contain cookies for multiple claude.ai accounts. It trips up the Oauth return and ensures chaos. My workaround has been manually switching between firefox and chrome as the default browser, but this is so so annoying. And chrome profiles aren't supported either so switching between profiles is also if not more annoying.

I have to switch browsers manually. Every. Single. Time.

Again the solution is parameterize (optional) to override the default and pick another browser with the 2nd accounts logged in credentials.

Additional Context

I can't be the first to report this annoyance. If there's something out there that figured it out I can't find it and spent lots of tokens searching for a bulletproof solution.

View original on GitHub ↗