codex auth login fails with "Port 127.0.0.1:1455 is already in use" on WSL

I encountered the same issue. Until the official fix is released, you can temporarily work around it using the following method:

1. Follow the steps in the official document "Connecting on a headless machine" (https://github.com/openai/codex/blob/main/docs/authentication.md#connecting-on-a-headless-machine).
2. Run codex auth login on the Windows host to complete the login (this will open a browser on Windows or provide an authorization URL).
3. After successfully logging in, copy the auth.json file from Windows (usually located at %USERPROFILE%\.codex) to the corresponding location in WSL (~/.codex/auth.json).
4. Then run the codex command that requires authentication from within WSL.

This avoids the port conflict caused by starting a local callback server until the official fix is released.

I ran into this on Mac with a Linux devcontainer running. Stopping the devcontainer fixed the issue and opened the login.

PS OpenAI, can we be a bit more graceful with the updates breaking authorization? My existing conversations just got 401'd after returning from the weekend.

I experienced the same error on Mac. I was using my local environment, instead of a virtual environment.

The cause was that I already had the Codex extension running on VS Code. Closing VS Code solved the issue.

so how？？？？？？？？

I was also getting this error on windows "An Attempt Was Made to Access a Socket in a Way Forbidden by Its Access Permissions’ (OS Error 10013)"

this fixed both errors on my end

net stop winnat
net start winnat

I run multiple devcontainer environment. Codex try to use 1455 port, but if not available, vscode automatically forward it to 1456, 1457... And It cause problem.

Manual auth token prompt should be added.

<img width="1341" height="84" alt="Image" src="https://github.com/user-attachments/assets/570b2b3c-785a-4e94-a8ed-08a1965c9b60" />

Would be nice if we could specify, or be prompted for, an available port to avoid having to shut down vscode when using the cli.

netsh interface ipv4 show excludedportrange protocol=tcp

Same here (os error 10013), I fixed it by ➝

net stop winnat
net start winnat

I tried to log into Codex CLI on two VS Code devcontainers at the same time as well as outside of the devcontainers and got this error.

Closing stale bugs.

If you run into this condition, it's likely related to your local network configuration (firewalls, VPNs, etc.).

As a workaround, you can use our headless device login mechanism.

Root cause identified for mirrored networking mode users

If you're on WSL2 with networkingMode=mirrored in .wslconfig, the Windows IP Helper service (iphlpsvc) holds port 1455 at the OS level, making it unavailable to WSL even though nothing WSL-side is using it.

Diagnose from WSL:

powershell.exe -Command "Get-NetTCPConnection -LocalPort 1455 -ErrorAction SilentlyContinue | ForEach-Object { \$proc = Get-Process -Id \$_.OwningProcess -ErrorAction SilentlyContinue; Write-Host \"PID: \$(\$_.OwningProcess) Process: \$(\$proc.Name)\" }"
# Output: PID: 5356  Process: svchost

powershell.exe -Command "Get-WmiObject Win32_Service | Where-Object { \$_.ProcessId -eq 5356 } | Select-Object DisplayName"
# Output: IP Helper

Permanent fix — switch to NAT mode in C:\Users\<you>\.wslconfig:

[wsl2]
networkingMode=NAT

Then wsl --shutdown from PowerShell and reopen WSL. NAT mode still relays localhost from Windows to WSL, so dev server workflows are unaffected.

I solved by using the headless device login mechanism after changing to NAT.

I've got an error when tried to login in Powershell. It's definitely a new bug because I didn't have this error before.

I've met the same situation on mac when I have a codex running on Cursor which seemed to be conflict with the offcial codex client. Exit the original cursor codex then everything runs smoothly

I ran into what looks like the same WSL issue and managed to get it working.

In my case the real problem was not an actual port conflict on 127.0.0.1:1455. The login flow from WSL could not launch the browser correctly, so the error was misleading and sent me in the wrong direction.

What fixed it for me was making sure the auth URL opens in the Windows browser, not inside the Linux side of WSL.

First, in VS Code / Kilo I had to make sure the external browser setting pointed to a real browser available on Windows. VS Code supports configuring the browser used for opening links via workbench.externalBrowser, instead of only relying on the system default.

Then on Ubuntu/WSL I installed wslu:

sudo apt update
sudo apt install wslu

After that I verified that WSL could open links in the Windows browser:

wslview https://example.com

Once that worked, the OpenAI login flow started working from WSL too. In my case I did not need extra port forwarding or localhost hacks after that.

So the workaround was basically:

1. Make sure VS Code / Kilo is configured to use a valid Windows browser for external links.
2. Install wslu in WSL so Linux-side link opening can forward into the Windows browser.
3. Retry the login flow.

It might be worth teaching Codex to detect WSL and prefer wslview automatically when available. Right now the error points people toward port debugging, even when the real issue is just that WSL cannot launch the browser properly.

when I close the cursor，the bug is fixed …