The Codex extension works normally in Cursor on my main Windows system, but it does not load when I open a project through WSL. The Codex panel stays stuck on the logo screen.
I have already tried:
Deleting ~/.codex
Reinstalling the extension in WSL
Deleting ~/.cursor-server
Restarting WSL and Cursor
Installing the same extension version manually from a Linux VSIX
The extension appears installed under WSL, but the UI still never loads. The Windows installation continues to work correctly.
Hey, thanks for the detailed report and the screenshot. Codex getting stuck on the logo specifically in WSL is a known pattern.
Codex is a third party OpenAI extension openai.chatgpt. On startup, its WebView loads a lot of asset chunks. In WSL this often fails, and the panel stays stuck on the logo. Since you’ve already cleaned everything on the WSL side, try these steps in order. These are the ones that help most often.
Turn off running Codex inside WSL. In the extension settings, disable Run Codex in Windows Subsystem for Linux. This is the most common cause of the WSL hang. The extension can get stuck on the OAuth port 1455 and on a synchronous WSL check during startup.
Make sure your project is stored on the native WSL2 filesystem, not in /mnt/c. Working from /mnt/c often breaks Codex and can be very slow.
Check that your distro is on WSL2, not WSL1. Quick check: wsl -l -v. If it shows 1, switch it with wsl --set-version <distro> 2.
Clear the WebView cache on the Windows side. Fully close Cursor, then delete these folders. They’ll be recreated on next launch:
%APPDATA%\Cursor\Service Worker
%APPDATA%\Cursor\Code Cache
%APPDATA%\Cursor\Cache
%APPDATA%\Cursor\GPUCache
Quick workaround: roll back and pin the extension to [email protected]. For some users this brings the UI back.
To see what’s failing, focus the Codex panel, run Developer: Open Webview Developer Tools, then check the console for errors like insufficient resources or net::ERR_FAILED on webview/assets/*.js.
