cli(login): add `--no-browser` flag to suppress auto-opening a browser during ChatGPT login

Resolved 💬 2 comments Opened Dec 28, 2025 by fkiller Closed Dec 28, 2025

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

What happened / problem statement

When running codex login (ChatGPT OAuth flow), the CLI attempts to automatically open the default browser. This is inconvenient (and sometimes impossible) in headless / remote / SSH environments, or when embedding the flow into another UI that needs to capture the auth URL and open it in a controlled browser context.

There is an open_browser toggle in the login server implementation (codex-rs/login/src/server.rs), but the CLI currently does not expose any flag to set it to false. Users can still copy/paste the printed URL, but the CLI always tries to open a browser first.

Why this is useful

Headless / remote machines: opening a local GUI browser is not viable.
SSH workflows: users may want to copy the URL and open it on their local machine (often via port-forwarding).
Embedded/controlled browser contexts: the application may want to intercept the URL and open it in an internal browser (or a specific browser profile), rather than the system default.

Proposed solution

Add a CLI flag to disable auto-open:

codex login --no-browser (or similar)
When enabled, do not attempt to launch a browser; print the auth URL with messaging optimized for manual copy/paste.

Additional context

I have a small patch ready that:

adds --no-browser to codex login
threads the flag through the ChatGPT login flow to the login server options
adjusts the printed message depending on whether auto-open is enabled
updates the authentication docs for headless setups

(Once this issue is created, I can open a PR that references it.)

Additional information

_No response_

View original on GitHub ↗

2 Comments

etraut-openai contributor · 8 months ago

We're tracking this feature in https://github.com/openai/codex/issues/2798.

We have a preview implementation of device code authentication that specifically targets this use case.

fkiller · 8 months ago

Thanks — makes sense to track the broader auth improvements in #2798, and I’m glad to hear there’s a preview device-code implementation.

One clarification: my primary use case isn’t only “remote/headless where localhost callback is unreachable”.
I also need a controlled-browser flow on the same machine/context (e.g., embedded webview or an app-managed browser) where I must intercept the auth URL and decide how/where to open it. In that scenario, a device-code flow may be helpful but it doesn’t directly replace the need to disable “auto-open the system default browser”.

That’s why the small --no-browser flag still seems valuable as an incremental improvement:

preserves the current default behavior
exposes the existing open_browser toggle in codex-rs/login/src/server.rs
enables deterministic/manual browser control for embedded or controlled environments

PR is here for reference: #8577