Support remote / headless OAuth sign-in

Workaround is to login locally and copy paste the auth.json file to the remote instance.

Another workaround is to copy as curl the failing callback and run it on the headless machine

I bought plus to try codex. I mainly use claude-code but tinker with gemini-cli and qwen coder, they all support this workflow. Cancelled my account because it's insufficiently convenient to use codex in a container (I'm not running it outside of one).

I was actually willing to curl the redirected url as @orysonc suggested but NB you really need _copy as curl_ eg. from dev tools to grab the headers too; the GET parameters are insufficient. Too much of a hassle to be a sustainable workaround for me.

Workaround: Complete Codex OAuth from a remote/headless machine using Firefox → “Copy as cURL (POSIX)”

Scenario
Codex CLI (codex login) runs on a remote box (VM/LXC/SSH/CI). Your browser is on a different machine. The login flow redirects to http://localhost:1455/auth/callback?..., which fails locally.
This workaround replays that failing browser redirect on the remote host by copying it as a full curl request (including headers).

Prereqs

Shell access to the machine where Codex runs.

Firefox on your local desktop.

Steps (copy-paste ready)

Start the login server on the remote host (Shell A) codex:

codex login
>_ Welcome to Codex, OpenAI's command-line coding agent > Finish signing in via your browser If the link doesn't open automatically, open the following link to authenticate:
https://auth.openai.com/oauth/authorize?response_type=code&client_id=app_EMoamEEZ73f0CkXaXp7hran..........

# Leave this running at "Press Esc to cancel"

On your desktop (Firefox): open the Auth URL printed by codex login, sign in.
You’ll land on a page that fails to reach http://localhost:1455/... — that’s expected.

Open Firefox DevTools → Network:

Press F12, switch to Network.

(Optional) enable Persist logs.

Re-trigger the failing redirect (click “Try again” or paste the full callback URL in the address bar and hit Enter).

Copy the failing request as cURL (POSIX):

In the Network list, right-click the GET …/auth/callback?... entry
→ Copy → Copy as cURL (POSIX).
(Do not choose “Windows”; do not copy just the URL.)

Back on the remote host (Shell B or screen, same machine as Shell A):

While codex login is still waiting, paste & run the copied curl command:

Example shape – yours will be longer and include headers:

curl 'http://localhost:1455/auth/callback?code=...&scope=...&state=...' \
-H 'User-Agent: Mozilla/5.0 ...' \
-H 'Accept: /' \
--compressed

Confirm success (Shell A):
codex login should finish with a “signed in” message. From now on, just run:

or Close /Break login process and restart codex , dont worry , OAuth is done:)

codex

Gotchas & Troubleshooting

Short-lived codes: If you see HTTP 400 State mismatch, start a fresh login:

Shell A

codex login

Then repeat Steps 2–5 with the new callback request.

Server must be listening: The callback server only exists while codex login runs.

ss -tlnp | grep 1455 || netstat -tlnp | grep 1455

Expect LISTEN on 127.0.0.1:1455 on the remote host

Connection refused → restart codex login, then re-run the cURL.

Use POSIX variant: “Copy as cURL (POSIX)” works on Linux containers.
The Windows cURL format won’t run cleanly on Linux.

Don’t strip quotes/line breaks: Paste the command exactly as copied. If it spans multiple lines with \, keep them.

Security: The callback URL contains a short-lived auth code. Treat it as sensitive; don’t share it.

Thanks for the copy auth.json workaround, it does work

I still think the CLI should support the headless OAuth flow I described. Tools like Claude Code or Gemini CLI already provide this, and it makes connecting much easier in shell-only or remote sessions without having to copy files around.

This really needs to be implemented natively. Claude Code and Gemini do it very simply, a link, go to it and auth, and that process seems to talk directly w/ anthropic/google servers to verify auth. Clean and works every time.

With codex, I've tried using an SSH tunnel and I get back an error, "ERR_EMPTY_RESPONSE", so it's getting through, but not working.

No matter what I do, or how quickly I run through the steps, all I get from the curl command is:
Token exchange failed: token endpoint returned status 400 Bad Request

Another workaround is to port forward 1455:localhost:1455 . Use codex login command on the remote server. Was able to paste the Auth URL on my local browser and the redirect worked correctly and logged me in.

Another workaround is to port forward 1455:localhost:1455 . Use codex login command on the remote server. Was able to paste the Auth URL on my local browser and the redirect worked correctly and logged me in.

ssh -L 1455:localhost:1455 youruser@your-linux-box-ip

for anyone needing the syntax for trying to access headless Linux from Windows.

I agree that this should be implemented. All these workarounds... looks like claude created them :)

No matter what I do, or how quickly I run through the steps, all I get from the curl command is: Token exchange failed: token endpoint returned status 400 Bad Request

I just went through the Firefox workaround - you really do have to use Firefox (or at least it happens to structure the CURL command correctly). I tried doing the same thing from the Brave browser and would get the 400 Bad Request error. Completely restarting the process seemed to work. I got no confirmation on the codex side ("Terminal A") that it worked, had to CTRL+C from codex login and just relaunch codex. /status confirmed that I am signed in to my Pro account.

yay, looks someone implemented a better auth method, hopefully it will be merged soon.

The fix with firefox worked for me. It has already been mentioned upward but mostly for future reference, make sure to use the copy as cURL(POSIX).

There are workarounds, but relying on workarounds for a feature that should've been there on day 1 isn't great UX.
The current auth flow isn't great, and the fact that I don't have this issue with competing products is pretty telling.

Workaround from @tedmarcin works on brave too (so should be working with other chromium based web browsers)

all I get from the curl firefox is Token exchange failed: token endpoint returned status 400 Bad Request too,

But the copy the auth.json works flawlessly and its easier

Setting networkingMode=VirtioProxy in .wslconfig allows the localhost callback to work. You will have to manually copy-paste the initial auth URL into your browser though.

it works fine for me if I open the 1455 port when running my docker container, just route it via ipv4
you dont need headless login, it would be nice, but routing the port to the host where you have a browser works fine

fully headless applications - yes still needs a fix

Thanks for the help, I was able to Oauth codex login, in my docker container, sequence was not the same in the guides people have posted here but it was helpful enough to figure it out, I had a certain window before it times out only a few seconds, I had to be quick to right click on the callback and paste it into my shell terminal.

@MFS2020

it works fine for me if I open the 1455 port when running my docker container, just route it via ipv4 you dont need headless login, it would be nice, but routing the port to the host where you have a browser works fine fully headless applications - yes still needs a fix

Could you explain this in more detail

@dimascior

Thanks for the help, I was able to Oauth codex login, in my docker container, sequence was not the same in the guides people have posted here but it was helpful enough to figure it out, I had a certain window before it times out only a few seconds, I had to be quick to right click on the callback and paste it into my shell terminal.

I started randomly getting this error
⚠️ stream error: exceeded retry limit, last status: 401 Unauthorized, request id: 98c4f1xxxxxxxx7b-EWR; retrying 1/5 in
212ms…

it basically lost my authentication which i had for a week, i am trying to replicate what i did and it is not working even with ipv4. @a428tm dimascior holds the key now lol, I am trying to figure it out if i do ill get back and share, this is so annoying...

@dimascior > Thanks for the help, I was able to Oauth codex login, in my docker container, sequence was not the same in the guides people have posted here but it was helpful enough to figure it out, I had a certain window before it times out only a few seconds, I had to be quick to right click on the callback and paste it into my shell terminal. I started randomly getting this error ⚠️ stream error: exceeded retry limit, last status: 401 Unauthorized, request id: 98c4f1xxxxxxxx7b-EWR; retrying 1/5 in 212ms… it basically lost my authentication which i had for a week, i am trying to replicate what i did and it is not working even with ipv4. @a428tm dimascior holds the key now lol, I am trying to figure it out if i do ill get back and share, this is so annoying...

exact same problem here

@myudak the only conclusion I can make is that they really don't want their codex to be used inside containers, because they identify those as actual pro environments, so they clock you out and expire your token, ill keep my eye on this, but this happens in the most inconvenient times...

It seems the new auth method still hasn't been released so I'm again trying to use the ssh tunnel.

I have it all setup, I've verified w/ netstat on the windows side, linux server I'm ssh'ed into AND in the docker container I'm using. All looks good as far as ports, etc.

I when I click through after putting the browser link in chrome, I get this:

This page isn’t working
localhost didn’t send any data.
ERR_EMPTY_RESPONSE

Anything I can do to troubleshoot the codex side? I've tried both codex login and doing a login from the console UI.

Workaround is to login locally and copy paste the auth.json file to the remote instance.

By the way, auth.json is under ~/.codex

I just hit this myself, so I'm bumping the conversation. This is not fixed in codex-cli 0.58.0

This is such an absurd bug that codex itself can easily fix. Claude Code has this.

so this never got fixed...

you have to ssh it works just very backwards

I found a convenient way to sign in from a remote/WSL environment when using Codex:

Use VS Code Remote (e.g. Remote - SSH or Remote - WSL) to connect to your remote environment and open your project there.

In that remote VS Code window, open the integrated terminal and run:

codex auth login
 ```

VS Code automatically sets up port forwarding for localhost:1455, so the login URL printed by codex works directly in your local browser and the OAuth flow completes successfully.

This avoids having to configure SSH port forwarding manually.

Note: This was tested with Visual Studio Code 1.106.2 (Electron 37.7.0 / Chromium 138.0.7204.251 / Node.js 22.20.0, Windows 10.0.22631 x64).

Thanks to Kenrick-Zhou Working solution : https://github.com/openai/codex/issues/3820#issuecomment-3306665091

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:

1. On your server, run codex login to start the login process (keep this session open).

1. The terminal will print out a long authorization URL.

On your Mac (I'm not very familiar with Windows), open a new Terminal and set up port forwarding to your server:

``ssh -N -L 1455:127.0.0.1:1455 <your_username>@<your_server>``

1. Open the authorization URL printed in step 2 in your Mac's browser and follow the login process.

1. You will see "Successfully logged in" if everything works correctly.

+1000 to making this flow easier like gemini cli and claude code!

Hi everyone! 👋

Thanks for all the discussion and feedback in this thread — it’s been super helpful. We’ve been building a device code authentication flow for the Codex CLI to make sign-in smoother for headless and remote environments, and we’d love your help testing it out. 🧪

How to try it

1. Upgrade the Codex CLI to the latest version.
2. Enable device code login in your ChatGPT security settings (personal account) or ChatGPT workspace permissions (workspace admin).
3. In a terminal you need to run codex, run:

``bash
codex login --device-auth
``

Then use the link to sign in with your account in your own browser and enter the one-time code.

What feedback is most useful

• Does it work in SSH-only/headless terminals, containers, or CI?
• Any rough edges in UX copy, browser ↔️ terminal handoff, timeouts, or retries?
• Platform quirks (macOS/Linux/Windows, WSL), proxies/VPNs, or network restrictions.
• Clear steps to reproduce issues, plus sanitized logs or screenshots.

How to share feedback

Please reply here with:

• Environment (OS & version, shell, terminal, network/proxy)
• CLI version (codex --version)
• What you expected vs what happened
• Any relevant logs (with secrets redacted)

Thank you for helping us make Codex better for everyone, and for being a thoughtful community! 💛

@mzeng-openai great to hear this is being resolved... but I just tried it inside a devcontainer, and I get this error below.. doesn't go to a step where it generates any link to copy paste in browser

⬢ [Docker] ❯ codex login --device-auth
Error logging in with device code: device code request failed with status 403 Forbidden

⬢ [Docker] ❯ codex --version
codex-cli 0.65.0

@epicwhale thanks for the feedback, ~~do you get 403 if you use this outside of a container?~~

update: it might be a firewall issue, we are working on a fix.

### How to try it 1. Upgrade the Codex CLI to the latest version. 2. Enable device code login in your ChatGPT security settings (personal account) or ChatGPT workspace permissions (workspace admin). 3. In a terminal you need to run codex, run: codex login --device-auth Then use the link to sign in with your account in your own browser and enter the one-time code.

works great, thanks, but its a roundabout way...
on claude code running on a server, we click the link and it just opens our browser and it shows a code to copy paste back to the terminal, then done. faster workflow.
still better than nothing, so thanks.

Hi,
I am sorry for my english.

I can login with these tasks without console or terminal.

Open vscode web normally.

Press sign in codex, in the new tab, I put user and passowrd, when convert url wirh localhost:1455/*****************
Go back to vscode tab
Down in the same flame of the terminal, Output, problem, etc, I have other tab with name ports
Press Add port and write 1455
You can see new line start with green led and copy Forwarded Address for the port 1455, in my case https://vscode.g.c**/proxy/1455/, then go to the tab with url localhost:1455 and reemplaze by my forwarded Address and press enter, again have change the URL with localhost:1455, remplace again with your fordwarded address and press enter.
You can see now the login is completed and now ya can go to vscode tab and start to work with codex.

<img width="696" height="177" alt="Image" src="https://github.com/user-attachments/assets/cfcbd885-e133-43ce-a029-704208e7d27a" />

My network configuration in the container of vscode is bridge.

Regards,
JP.

Hi everyone! 👋 Thanks for all the discussion and feedback in this thread — it’s been super helpful. We’ve been building a device code authentication flow for the Codex CLI to make sign-in smoother for headless and remote environments, and we’d love your help testing it out. 🧪 ### How to try it 1. Upgrade the Codex CLI to the latest version. 2. Enable device code login in your ChatGPT security settings (personal account) or ChatGPT workspace permissions (workspace admin). 3. In a terminal you need to run codex, run: codex login --device-auth Then use the link to sign in with your account in your own browser and enter the one-time code. ### What feedback is most useful Does it work in SSH-only/headless terminals, containers, or CI? Any rough edges in UX copy, browser ↔️ terminal handoff, timeouts, or retries? Platform quirks (macOS/Linux/Windows, WSL), proxies/VPNs, or network restrictions. Clear steps to reproduce issues, plus sanitized logs or screenshots. ### How to share feedback Please reply here with: Environment (OS & version, shell, terminal, network/proxy) CLI version (codex --version) What you expected vs what happened Any relevant logs (with secrets redacted) Thank you for helping us make Codex better for everyone, and for being a thoughtful community! 💛

Interestingly, this "kinda" works, but clicking the "enable" link in the device auth process flashes the settings panel where you see the checkbox to toggle it on/enable it, but it goes away within seconds (before you can click it).

😱

I consistently get this screen with the device auth. None of the other suggested workarounds worked for me either.

<img width="509" height="324" alt="Image" src="https://github.com/user-attachments/assets/8f49cd49-7cb8-439a-b668-79748335f432" />

I turned on device codes, then tried logging in. FAIL!

I am given this link: https://auth.openai.com/codex/device which forwards me to the regular https://auth.openai.com/log-in, which shows the regular login options. No code input whatsoever ;|

I think this issue currently mixes multiple problems (auto-opening a browser, localhost callback/redirect limitations in remote/headless setups, and broader “device-code/hosted redirect” design).

To make incremental progress, I opened a small PR that addresses just one isolated piece: disable auto-opening a browser and print the auth URL.

PR: https://github.com/openai/codex/pull/8577

This is intentionally scoped and does NOT solve the bigger localhost redirect limitation; it only reduces friction for controlled-browser flows (embedded webviews, environments where spawning a GUI browser is undesirable) while a larger design is discussed separately.

@24601 It used to unnecessarily restrict access to certain users but should have been fixed now and you shouldn't see the flash again. Please try again and let me know if it works.

@sztomi do you mind sharing the steps to reproduce?

@Morriz You'd need to log in through that page first and then input the code. Let us know how we can make the instructions more clear.

Enable device code login in your ChatGPT security settings (personal account) or ChatGPT workspace permissions (workspace admin).

I'm on a business account but I don't see any settings to enable it. I can't login using a device code as I keep getting kicked out with a notification I should contact a workspace admin.

@mzeng-openai I followed these steps: https://github.com/openai/codex/issues/2798#issuecomment-3673286359

Also on a business account, I don't see the setting to allow device login, neither in personal nor workspace admin.

I'm going to close this feature request because the functionality is now in place.

@ahcm & @sztomi, if you're running into problems using this functionality, please open bug reports and provide details about the problem you're seeing.