Nothing off the above worked for me. I deleted the extension, removed the .codex folder, uninstalled codex_cli, tried the 04.12 version but it still is not opening the connection dialog so that I can log in. It worked till yesterday though, but I guess that the new release that was installed automatically has mixed up things. Do you guys have a hint what I could do to solve this?
The thing that finally worked for me was deleting the CODEX_HOME environment variable. This thing was pointing to something not correct and as soon as I got rid of it I could again log in with VS Code and resume working.
This has fixed my issue in Windows 11
This exactly solved my problem.
Thank you! 
Hola, me funciono esta opción. Instale latest y reinicie VSC. El error se fue y carga todo bien una vez que reinicie VSC.
Pd: Parece que trabaja con VSC y VS 2022 por igual.
Yeah this is the only fix that has worked for me . Thanks
For me the solution was to go into Codex settings and uncheck “Run Codex in Windows Subsystem for Linux”. As soon as I did that the side panel loaded and asked me to sign in to OpenAI.
I do have WSL (v2) installed and running. I use it all the time (outside of vscode).
I’ve tried all the other ideias, but this was the most simple one and obvioslly the last one that actually solved the issue for me hahha.
Similarly for me, simply starting up Docker Desktop seemed to fix the issue. My guess is that because I run Codex inside of devcontainers, it stored some things on Docker that then caused it to fail when Docker wasn’t running.
I solved my problem fixing the Codex dependencies:
If you are trying to run it on Windows, check if you have all the dependencies installed
Python3 and Microsoft Visual C++
———————————————————
To install python execute on windows command prompt these commands below:
winget install --id Python.Python.3.13
If you are running Windows on 64bits
winget install Microsoft.VCRedist.2015+.x64
else
winget install Microsoft.VCRedist.2015+.x86
I was able to fully diagnose (and temporarily work around) this issue on Windows 11 + WSL. The root cause seems to be a hard-coded OAuth callback port colliding with Windows excluded port ranges in my case.
Key findings:
-
The Codex VS Code extension hardcodes the OAuth loopback callback to 127.0.0.1:1455.
-
On my system, Windows has TCP ports 14438–14537 excluded:
netsh interface ipv4 show excludedportrange protocol=tcpThis includes 1455, so Windows will never allow a process to bind it (even if nothing is listening).
-
This causes:
-
Windows mode →
os error 10013/ “access forbidden” -
WSL mode → login hangs forever waiting for browser redirect
-
Important detail:
In WSL mode, Codex does start a real OAuth callback server (Rust tiny-http) on 127.0.0.1:1455 inside WSL. OAuth completes successfully (302 → /success?id_token=…). However, the VS Code extension only completes login when the browser itself follows the redirect — curl/manual requests do not trigger completion.
Because the browser is launched on Windows, and Windows cannot bind or route port 1455, the redirect never completes and Codex stays stuck.
Confirmed workaround:
-
Enable “Run Codex in WSL”
-
Launch a browser inside WSL (e.g.
firefoxvia WSLg) -
Paste the full OAuth callback URL into that WSL browser
-
Login completes immediately
Suggested fix:
-
Allow the callback port to be configured in extension settings
-
OR provide a copy-paste/manual completion fallback
Hardcoding a localhost OAuth port on Windows is fragile due to excluded port ranges created by Hyper-V / WSL / VPNs.
I figured it out in my case:
My browser tried to send the data to localhost:1455 , because port 1455 is already in use by another process (likely a hung background. So what I do was just kill this pid, and redit it. it worked for me.
Find the process holding the port:
-
Windows (PowerShell):
netstat -ano | findstr :1455 -
Linux/Mac:
lsof -i :1455ornetstat -nlp | grep 1455
Kill it:
-
Windows:
taskkill /PID <PID_FROM_ABOVE> /F -
Linux/Mac:
kill -9 <PID>
Installing the latest Visual C++ Redistributable v14 worked for me.
I guess the cause differs for everyone. In my case, it was because I forgot to unset the CODEX_HOME environment variable that I set last year while trying Speckit.
For those still having this problem, try opening the Output tab (Ctrl+Shift+U) and then choose Codex as the output source. You might see the cause there. You could also copy that output and paste it when asking for help here or when asking an AI.
Fix: Codex Stuck on Loading Screen (VS Code)
If Codex is stuck on the loading screen and logs show:
Codex process exited unexpectedly (code=3221225781 / 0xc0000135)
Solution
Install the required runtime dependencies:
-
Microsoft Visual C++ Redistributable 2015–2022 (x64)
-
Microsoft Visual C++ Redistributable 2015–2022 (x86)
Then restart your PC.
If It Still Doesn’t Work
-
Open VS Code Output panel:
View → Output (Ctrl + Shift + U) -
Select:
Codex -
Check the first error message — that is the real root cause.
Common Issues
-
0xc0000135→ Missing DLL → Install VC++ Redistributables -
Codex process is not available→ Restart VS Code / reinstall extension -
stdin destroyed→ Backend crash → check earlier logs
Tip
This issue is usually caused by missing system dependencies, not a bug in the extension UI.
what worked for me :
click on settings icon in codex → go for “'codex setting” option → click on ‘Open config.toml’
you will get your current configuration , i just did
'model = “gpt-5.4”
model_reasoning_effort = “medium”
’
after changing save the file and restart your vscode. Easy 
The above solutions did not seem to work in my case. Here is what worked for me.
My issue had two causes:
1. IPC socket permission error (EACCES)
On shared Linux systems (e.g. SLURM clusters), the Codex extension creates an IPC socket directory at /tmp/codex-ipc/. The first user who runs Codex creates this directory with their own permissions (drwxr-xr-x), which blocks all other users from creating their sockets inside it.
The error in the logs looks like:
[IpcRouterManager] Server error errorCode=EACCES errorMessage="listen EACCES: permission denied /tmp/codex-ipc/ipc-<UID>.sock"
Fix: I patched the extension source (extension.js) to use a per-user directory instead of the shared /tmp/codex-ipc/. In the minified JS, I replaced:
let t=yR.join(mie.tmpdir(),"codex-ipc")
with:
let t="/home/<myuser>/.codex-ipc"
The file is located at:
~/.vscode-server/extensions/openai.chatgpt-<version>-linux-x64/out/extension.js
Note: This patch gets overwritten on extension updates, so you’ll need to re-apply it. Ideally OpenAI should either use a per-user subdirectory or create
/tmp/codex-ipc/with1777permissions (sticky bit, like/tmpitself).
2. Corrupted SQLite databases
After fixing the IPC issue, Codex still wouldn’t start. Running the binary manually revealed the real error:
Error: failed to initialize sqlite state runtime under ~/.codex: error returned from database: (code: 26) file is not a database
Two SQLite files in ~/.codex/ (state_5.sqlite and logs_2.sqlite) were corrupted (showed as generic “data” instead of “SQLite 3.x database” when checked with the file command).
Fix: Renamed the corrupted files and let Codex recreate them:
mv ~/.codex/state_5.sqlite ~/.codex/state_5.sqlite.bak
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
After both fixes + a VS Code reload, Codex loaded normally.
Might be worth suggesting per-user IPC dirs by default instead of a shared /tmp/codex-ipc path. On multi-user systems the first-created permissions can easily lock everyone else out unless the parent dir uses something like 1777.
The SQLite corruption finding is a really good catch too.. damn
I have the same issue. you can press view–> output; select codex to see what is the error message. For me, it is because /home folder is full ( 100 % ) so .codex cannot write ; after cleaning up space it works fine