Enable Headless or Command-line Authentication for Codex CLI (ChatGPT Plans)
What feature would you like to see?
Current State: To authenticate Codex CLI for ChatGPT Plus and other plans, users must click a web link as part of an OAuth flow (“Sign in with ChatGPT”). This process requires a browser/UI, making it difficult to use on headless servers or Linux systems with no GUI.
Why This Matters: Many developers use Codex on remote Linux environments or in CI/CD pipelines. The current web-based sign-in interrupts automation and makes setup on GUI-less systems cumbersome or impossible.
Requested Improvement: Please add support for headless authentication—such as direct API key provisioning, CLI-based flow, or device code authentication—for users on ChatGPT-linked plans. This would make Codex usable in more environments, especially for advanced users and teams relying on automation.
Are you interested in implementing this feature?
_No response_
Additional information
_No response_
34 Comments
This is indeed an annoying issue, and I hope it can be resolved soon.
However, before an official solution is provided, you can try the following steps:
codex loginto start the login process (keep this session open).The terminal will print out a long authorization URL.
``
bash
``ssh -N -L 1455:127.0.0.1:1455 <your_username>@<your_server>
Super annoying. Please fix.
@Kenrick-Zhou and @servaasvdc , thanks for your support! I was able to to get the workaround Kenrick mentioned working. Since a competing company's coding agent supports conventional command line logins, I will probably use that until I reach my 5 hour usage caps. At least I will have a fallback option to Codex in those cases. Hopefully a permanent fix will be implemented so I can use Codex as my primary. It sounds like other people will find this enhancement beneficial too.
I ran into this and got this response from OpenAI support-bot:
The ssh port forwarding workaround in this thread is mentioned (though slightly different approach here) and it mentions how to copy credentials (I found this easier because of firewall restrictions for me).
It used to work that you could start codex on a remote machine, copy the oauth link to local, and the remote codex would get the auth information and startup. It looks like this was intentionally broken for "security reasons". The token has some unknown expiration time, but if you login to a previously authenticated Codex instance your token will get refreshed. For CI/CD, as a terrible hack, you might be able to authenticate codex on a machine, before your pipeline runs login to codex to refresh your token, copy the token into your pipeline and use it to pass the initial codex authentication check. After this initial authentication a new auth token is generated when you start codex if the old token has expired (at least, in my experience, I don't think this is documented).
Please, please fix this soon. This is litterally the one thing preventing full, uninterurpted automation, for several workflows/use cases.
One other workaround I found was using vscode from a machine that has a UI, but with the vscode container in the headless machine. If you start codex in the vscode terminal the link it comes back with is clickable and will open a chromium browser on the "outer" vscode (where you have a UI). Then you can click through the auth flow and the auth token will be set. Obviously, this doesn't "solve" things but was more convenient than the other approaches for me and worth mentioning. Hopefully they reverse the security "decision" that's broken this flow (I think being able to set whitelist of allowed ips for completing the auth flow is needed).
Please fix this issue at the earliest. Its a blocker
The good old ssh tunnel! Nice solution.
The issue here is not how you get authenticated. It's that you have to log in again after a while, breaking automation. Codex is unusable in CI/CD pipeline on a subscription. They are pushing you to use the OPENAI_API_KEY for that.
@etraut-openai @pakrym-oai @aibrahim-oai would it be possible to support a solution similar to Claude Code or Gemini where we can pass an auth code, instead of having the redirect? Right now it redirects to
http://localhost:1455/auth/callback?code=ABCD&scope=openid+profile+email+offline_access&state=ABCD, but that clearly is an issue in backend environments.@papay0, can you describe your use case in more detail? When you say "backend environments", are you running codex cli in a server environment? The OpenAI API key is typically used in server use cases (
codex login --api-key <key>). Does that meet your needs?You can just copy the auth token (at least you can in .39 and earlier, it's what I doing my CI/CD) to the home/.codex directory (auth.json) which I think is basically what "passing the token does" but Claude obfuscates the "token" (AFAIK). After you do this initial manual setup, from that point on the auth token will get refreshed (either on invocation, or automatically if it's expired, I'm not 100% sure how it works). The result, though, is that if you have a build system with Codex installed, you manually authenticate, then you invoke a dummy codex call (
codex "prompt to execute"or start it as an mcp server:codex mcp) the auth token on the build machine will be "fresh" (build-host:home/.codex/auth.json and if you install codex on the target, you can then drop the auth token into target-host:home/.codex/auth.json) and when you initially run codex on the target it won't ask you to manually authenticate. Then on the target, if you run codex again and auth token has expired, it will automatically refresh. At least, this has worked for me, but it's not documented and it's probably not intentional so I wouldn't bet on it continuing to work.I think the behavior change (making the link specific to the machine running codex not working if you copy it to another browser because the originating machine is headless or in an automated CI/CD workflow) is a response to a security issue that was found and publicized a few days ago (https://verialabs.com/blog/from-mcp-to-shell/ was on hacker news front page a few days ago), so I think we probably don't get this functionality back because it was "broken".
I think what we need is the ability to have a
codex loginthat will generate an auth token that will work for some user controlled "whitelist" of machines. The security issue was really about this working for "any domain" and some nefarious mcp servers that could leverage this to get exfiltrate data from your machine. I think this "explicitly specified set of whitelisted domains that can use the token" would solve the security problem and solve the real CI/CD pain that this change has caused.I mean "it works", but I think "server environment" isn't really much of a crisp "segmentation" and it disallows using Codex with your ChatGPT subscription (a very big part of the Codex "value").
I have a pro account, I work on a bunch of personal projects. To allow codex to run "danger full" I create devcontainers, deploy my code, install codex, step into the container and develop from there. My devcontainers are headless, and manual authentication that used to work (I could run codex in the devcontainer, it gives me a link, I copy that to my real dev machine browser, the communication that "I authenticated in the browser gets routed back to the Codex install I initiated the authentication request from" was broken in .37 or .38 (I think, somewhere around there). That's a perfectly "not business use case" and it seems pretty arbitrary and unfair to say "ChatGPT login can be used with Codex unless you use it on a headless system, then you need an API". All the work arounds in this thread (I think) are a response to "how do we get Codex on a headless machine to authenticate when the authentication process effectively requires a browser on the machines that Codex was installed to.
There are ways to make this work, but they're all hacky, not documented, and there's no real understanding (at least from me) of what's "in bounds" in trying to make this work. If you tell me this "develop in a devcontainer" workflow isn't supported, use an API key, fair enough, but I think this is the way that everyone should be developing given the occasional "real bad mess up" that these CLI agent "tools" are capable of, and it's sort of broken right now.
Here is the description of my issue https://github.com/openai/codex/issues/4318
Signing in with the subscription (instead of API key) is a big plus for Codex, and right now it's very hard to do from the CI, or non-local dev environment
EDIT: Apparently, you (OpenAI) are working on something to fix it? https://x.com/embirico/status/1971701874257809819
Please fix this issue at the earliest. Its a blocker
work around no longer possible on my remote host due to firewall constrains -hopefully this will be resolved soon and implement the same system anthropic uses for Claude.
Yeah disappointing this is not fixed yet.
this question is quite strange, people use virtual machine, or vps, or even headless home server all the time for development use case, especially since many server-side app are Linux while the Dev use Win/Mac machine. So the issue is quite valid, even without assuming that the target machine is a full blown "server".
the fix could be very simple like have the cli spit out a oneliner command for ssh local forwarding (which as a matter of facts many Dev are not familiar with, hell i even know of network engineer who's more geared toward L2/L3 stuff that are not familiar with that), or have the browser spit out a token string that user can manually paste back into the CLI setup process (git kraken often fall back to this).
Current state of things is that people have to google the fix, then follow it
Another solution (testet with version OpenAI Codex v0.44.0).
This has already been described here in a similar way by other users. However, you do not need SSH forwarding for this.
Well, that was actually quite obvious when I think about this, lol.
Thanks brother.
That process has always worked. I think the real issue is that it can't be automated. So, when/if that token expires (or the tokens contained in auth.json), your automated workflow is broken, until you do the "manual" process of regenerating auth.json. Earlier this year, the token seemed to expire like every month for me. But now, it seems to be a long lived token of some sort (it's been several months now for me). Neverthless, if the contained token does eventually expire, any automated flow is broken until one manually regenerates...right?
Currently, this is the biggest reason I'm sticking with the Claude Code. I regularly switch the machines and LXD containers for daily research and development, and sometimes hope to set up a new LLM coding environment. I'm not sure why the Codex CLI is taking this weird approach......
stick to cc unless it's fixed
lol i just told claude to do that for me and it worked.
Please fix this asap . maybe add a third auth option. its too hard to use codex on servers . ty
Blown away that this is this difficult to do. I want to use my OpenAI Plus subscription to launch Codex CLI in dev containers, so I don't have to worry about Codex CLI touching things it shouldn't. Anthropic provides a full dev containers walkthrough, yet I'm on hour 5 or so of trying to get Codex CLI dev containers working, with GPT5 totally failing to figure it out either. Can OpenAI please publish a first-party dev containers guide so we aren't all struggling with this?
@etraut-openai - Similar to others' comments, I too look forward to this issue being fixed.
My use case is that I want to run
codex(like all my agents) in a headless sandbox (eg, a VM, but it could be an lxd/incus container, docker/podman/systemd-nspawn container, etc) where there is no browser and I want to use SSO to authenticate instead of using an API key. As others have mentioned, headless environments are an important use case for a variety of reasons (mine is security).With claude code, this works perfectly: enter the sandbox environment, run
claude(eg,/login) andclaudedisplays a URL with a prompt to enter an authentication code; click that URL which opens in the host's browser (not the sandbox); do SSO and click 'authenticate' and the browser displays a code to give to the prompt; then enter that code into the claude prompt.With gemini-cli, this also works (note, https://github.com/google-gemini/gemini-cli is Apache 2.0 licensed, so you could see what they are doing).
With
codex, this doesn't work: after runningcodexwithin the headless sandbox and choosing 'Signin with ChatGPT':codexsets up the terminal)codex) allows one to SSO, but with aredirect_uri(eg, `https://auth.openai.com/oauth/authorize?response_type=code&client_id=...&redirect_uri=http%3A%2F%2Flocalhost%3A1455%2Fauth%2Fcallback&scope=openid%20profile%20email%20offline_access&code_challenge=...&code_challenge_method=S256&id_token_add_organizations=true&codex_cli_simplified_flow=true&state=...&originator=codex_cli_rs
) tohttps://localhost:1455/...`AIUI, there are two problems:
codexisn't presenting a URL that is clickable within a headless environment (Linux/bash terminal)codexshould use some sort of Device Authorization flow for CLI commands. Eg https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow#how-it-worksIME,
codexshould be adjusted to detect its environment and if headless, use an authentication flow specific to CLI commands.As others have mentioned, installing codex on the host, logging in then copying
~/.codex/auth.jsonto the sandbox 'works' in thatcodexin the sandbox can proceed without authenticating, but this is highly inconvenient and will only last until it expires.Hopefully this helps with use cases on why the headless CLI experience is valuable to your users along with some tips on how to proceed. Thanks!
this is not codex bug, it's oai does not support oauth code flow.
Fyi,
@github/copilotalso works.Tried codex CLI today for first time after being a claude code user, this was definitely the most jarring aspect of switching over, having to set up SSH tunnels to server as a workaround just to do a basic login. While that worked it's definitely not a smooth experience when users have search for a solution and read comment threads on a GitHub issue just to complete the login process.
+1 to all of this. Wanted to give codex a shot (long time Claude Code user) and this is a really rough start for me. Please fix this! I run a devbox on a Proxmox LXC so I can remote ssh in from any PC. Pretty standard use case.
Just download vscode and use the vscode terminal for login after ssh connection and then it work on the rest of your pc. That's what I end up doing. If you don't use vscode then I can't help you.
Closing this in favor of #2798, which has more upvotes.
This really works for me