Help test the Codex IDE Extension with Windows WSL

[ae-openai]

Hello! Thanks to all of you who've provided feedback and contributions since the Codex CLI and IDE extension launched. We have a few improvements coming for the IDE Extension on Windows, and we'd love your help testing and improving.

To start, today's prerelease build supports using Windows Subsystem for Linux (WSL2) to run commands in bash, for better performance and fewer approvals with sandboxing.

How to test:

1. Install wsl by running wsl --install as admin
2. Update the extension to the latest release (0.4.34)
3. Restart VSCode
4. Enable the chatgpt.runCodexInWindowsSubsystemForLinux setting in VSCode Settings
5. Restart VS Code

Sharing feedback

We'd love to know how this works for you. Please reply to this discussion with your questions and feedback.

Thanks for helping us improve Codex on Windows!

[Kbediako]

I've set up a new project to test these changes, and the results are positive:

• Codex is correctly utilizing the bash commands, and they are executing successfully.
• Token usage is noticeably lower, as the model no longer needs to iterate to find the correct commands.

[ae-openai]

thank you for testing! please keep us posted as you encounter things to improve :)

[Kbediako]

Recreated a mini project for testing.

Had a drastically reduced error rate in terms of bugs during implementation and about 30% more context to spare per task completion. No command issues either.

Overall, this has been a great update 👍 cheers guys.

[sfz009900]

i get a error:

2025-10-22 09:07:40.462 [error] Unknown MCP notification: codex/event/user_message {"id":"0","msg":{"type":"user_message","message":"<environment_context>\n  <cwd>/mnt/d/task/myself/python/fuckfanyi</cwd>\n  <approval_policy>on-request</approval_policy>\n  <sandbox_mode>workspace-write</sandbox_mode>\n  <network_access>restricted</network_access>\n  <writable_roots>\n    <root>/mnt/d/task/myself/python/fuckfanyi</root>\n  </writable_roots>\n</environment_context>","kind":"environment_context"},"conversationId":"019a0975-1892-7532-a8e8-f8824f0ada75"}
2025-10-22 09:07:43.663 [warning] CLI: codex_core::codex: stream disconnected - retrying turn (1/5 in 207ms)...
2025-10-22 09:07:47.131 [warning] CLI: codex_core::codex: stream disconnected - retrying turn (2/5 in 439ms)...

[Kbediako]

Update Codex IDE/CLI and any MCP components so they’re on the same minor/patch line.

• Also noting this is primarily for IDE extension on VScode.

[dylan-hurd-oai]

Resolved in #5471 (comment)

[sfz009900]

Yes, I am getting this error in the vscode environment as soon as I open the preferWsl option.

[Kbediako]

Try the following:

• Remove all MCP configs
• Try running from a non /mnt/ mount
• If you use adblock or custom DNS disable it

[ae-openai]

for the record, this was resolved in #5471 (comment)

[sfz009900]

@Kbediako I found the cause: it was due to Proxifier being installed on my Windows. Disabling it resolved the issue.

[sfz009900]

@Kbediako The FAKE IP caused by Proxifier's DNS resolution through a proxy.

[Kbediako]

Glad to hear it's resolved! Drop any other issues you have here so we can improve the WSL experience for everyone.

[sfz009900]

@Kbediako I have posted this topic to other forums to get more testers. :)

[sfz009900]

@Kbediako However, if I use MCP with a configuration like the following:

[mcp_servers.context7]
command = "F:\\software\\nodejsold\\npx.cmd"
args = ["-y", "@upstash/context7-mcp", "--api-key", "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]
startup_timeout_ms = 20_000
env = { APPDATA="C:\\Users\\test004\\AppData\\Roaming", LOCALAPPDATA="C:\\Users\\test004\\AppData\\Local", HOME="C:\\Users\\test004", SystemRoot="C:\\Windows", ComSpec="C:\\Windows\\System32\\cmd.exe", NPM_CONFIG_REGISTRY="https://registry.npmmirror.com" }

You will then get the following error:
2025-10-22 11:07:18.398 [error] CLI: codex_core::codex: MCP client for context7 failed to start: No such file or directory (os error 2)

[sfz009900]

@Kbediako The MCP issue hasn't been resolved yet, but I don't need to use MCP for the time being :)

[drhurd]

@Kbediako @sfz009900 thanks for all the commentary here! For context, we made a call to pull in the Windows config.toml because we were primarily considering users who were earlier in their adoption cycle - e.g. this allows us to maintain your auth if you haven't logged in on WSL. But clearer mcp support is a very convincing argument otherwise.

Switching back to using the WSL config.toml is an easy fix - I'll push a new pre-release in a couple hours with this change.

[Kbediako]

Glad to help :) thanks for the speedy update

[ae-openai]

https://github.com/openai/openai/pull/527035 by @drhurd 🙌

[dylan-hurd-oai]

Fixed in 0.5.23 - you can automatically pull up the correct config.toml using the settings dropdown in the extension:

[sfz009900]

Then there is the issue of MCP. I will give an example of this issue in detail.

I am using the following MCP configuration.

[mcp_servers.context7]
command = "F:\\software\\nodejsold\\npx.cmd"
args = ["-y", "@upstash/context7-mcp", "--api-key", "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]
startup_timeout_ms = 20_000
env = { APPDATA="C:\\Users\\test004\\AppData\\Roaming", LOCALAPPDATA="C:\\Users\\test004\\AppData\\Local", HOME="C:\\Users\\test004", SystemRoot="C:\\Windows", ComSpec="C:\\Windows\\System32\\cmd.exe", NPM_CONFIG_REGISTRY="https://registry.npmmirror.com" }

When I don't use preferWsl, this MCP can be used normally.

But if you use preferWsl, you will get the following error message.

2025-10-22 11:07:18.398 [error] CLI: codex_core::codex: MCP client for context7 failed to start: No such file or directory (os error 2)

[Kbediako]

I'll take a look at this in the morning and try to recreate it.

[Kbediako]

@sfz009900 Inside WSL, that path/launcher(F drive) doesn’t exist (and .cmd isn’t a Linux executable), so Codex errors. The WSL prerelease explicitly routes execution into WSL bash, which is why this shows up only when preferWsl is enabled.

[4erdenko]

The extension is actually using Windows config toml instead of the WSL2 version.

[drhurd]

@4erdenko this is correct - copying my comment above:

For context, we made a call to pull in the Windows config.toml because we were primarily considering users who were earlier in their adoption cycle - e.g. this allows us to maintain your auth if you haven't logged in on WSL. But clearer mcp support is a very convincing argument otherwise.
Switching back to using the WSL config.toml is an easy fix - I'll push a new pre-release in a couple hours with this change.

[ae-openai]

https://github.com/openai/openai/pull/527035 by @drhurd 🙌

[dylan-hurd-oai]

This has been fixed in 0.5.23

[janpio]

I asked Codex (gpt5-high) to create a simple browser extension in an empty folder (C:\Projects\foo-bar), it tried to create the frist file twice via WSL before then falling back to PowerShell:

apply_patch is failing in this environment. I’ll create the files using PowerShell in the workspace and add the content script next.

That also seems to fail because of permission issues. VS Code itself can create files just fine (via UI and terminal).

After telling it You should be able to create them via WSL/bash. it debugged a bit, and finally figured out a way to create the files.

Afterwards it realized the file content was not as expected though:

Oh no, it looks like the files got corrupted. The 'style.textContent' is empty, and weird placeholders like 'uid=1000...' appeared in the README. Some necessary content has been replaced with nothing. I suspect this happened because of using 'bash', which seems to have performed unwanted variable expansions during substitutions, even though we used '<< 'JS''. This indicates that backticks or similar commands may have processed the content incorrectly. I need to dig deeper into this!

It did, and then created a working extension.

[janpio]

@Kbediako All default (new installation), but enabled Prefer Wsl.

[janpio]

Ok, after a VS Code restart I now had gpt-5-codex * available as the model (I wondered a tiny bit before, but didn't dig deeper and just accepted that as normal...), and with that it just worked.

Does it make any sense that it was not available before, or did I just mess up?

[Kbediako]

Same issue here. Seems like when the workspace lives under /mnt instead of the WSL ext4 volume, the filesystem doesn’t behave like native Linux.

Codex and its tooling probably rely on WSL ext4 native semantics(permissions/exec bits, file watching, case sensitivity, and I/O) to pick and execute bash commands reliably. Moving the repo to the WSL disk (e.g., ~/code) and enabling chatgpt.preferWsl resolves it for me.

Maybe just have two copies of the repo on your device? Backup on C drive and working version in WSL disk.

[ae-openai]

@4erdenko: Reading this, it sounds like this was fixed after restart is that right? We'll make it so you don't have to restart

[janpio]

After a night of sleep I tried to recreate the situation I ended up in yesterday, but the codex models were available instantly after extension installation, so I have no idea what went wrong yesterday 🤷.

If there is no way for the extension to run only with the normal gpt-5 models (without codex), then I must have missed them and been led down the unhappy path because of that.

[ThoughtPhotography]

0.5.23 is out, but unless I'm missing it there's no changelog and the release page only covers the CLI.
Knowing what's changed makes it easier to know what to test.

[dylan-hurd-oai]

We do not typically add release notes for pre-releases - added notes below!

[sfz009900]

I'm using the latest 0.5.23 version and configured the latest MCP under WSL.
/home/test004/.codex/config.toml

[mcp_servers.context7]
args = ["-y", "@upstash/context7-mcp", "--api-key", "xxxxxxxxxxxxxx"]
command = "npx"
startup_timeout_ms = 30_000

But you will still get the following error report.
2025-10-23 14:33:54.471 [warning] CLI: codex_core::codex: MCP client for context7 failed to start: No such file or directory (os error 2)

[sfz009900]

Another problem is that if the implementation of MCP is put under WSL, it will be very inconvenient when using MCP, right?
For example, if I want to install the MCP chrome-devtools-mcp, it needs to configure Google Chrome and install this browser under WSL. This situation would cause great inconvenience.

[sfz009900]

@ae-openai I think it would be helpful to add some more detailed debugging logs. I can send you a more detailed explanation of the MCP error cause.

[dylan-hurd-oai]

@sfz009900 good feedback! Is npx / context7 installed in your WSL environment? Or are you trying to invoke your windows installation?

Re: invoking windows native tools, it is still possible, but I think we need some fixes on how we set PATH variables...WSLENV has been very tricky to get working. I'll work on some fixes there, but it will require using command_to_run.exe instead. We can update docs as needed, but it should match CLI behavior under WSL.

Re: debugging, is the problem that Output > Codex has insufficient information, or that those logs are hard to find / hard to work with?

[sfz009900]

@dylan-hurd-oai
Yes, it works fine when I run context7-mcp under WSL.

npx -y @upstash/context7-mcp
Context7 Documentation MCP Server running on stdio

[sfz009900]

@dylan-hurd-oai
In the latest version 0.5.26, the same error message will still appear in MCP.

/home/test004/.codex/config.toml

[mcp_servers.context7]
args = ["-y", "@upstash/context7-mcp", "--api-key", "xxxxxxxxxxxxxxxxxxxxx"]
command = "npx"
startup_timeout_ms = 30_000

2025-10-24 10:17:14.159 [warning] CLI: codex_core::codex: MCP client for `context7` failed to start: No such file or directory (os error 2)

However, if I turn off preferWsl and set MCP in the Windows configuration file, it works.

C:\Users\test004\.codex\config.toml

[mcp_servers.context7]
command = "F:\\software\\nodejsold\\npx.cmd"
args = ["-y", "@upstash/context7-mcp", "--api-key", "xxxxxxxxxxxxxx"]
startup_timeout_ms = 20_000
env = { APPDATA="C:\\Users\\test004\\AppData\\Roaming", LOCALAPPDATA="C:\\Users\\test004\\AppData\\Local", HOME="C:\\Users\\test004", SystemRoot="C:\\Windows", ComSpec="C:\\Windows\\System32\\cmd.exe", NPM_CONFIG_REGISTRY="https://registry.npmmirror.com" }

[dylan-hurd-oai]

0.5.23 is out with a couple fixes here:

• uses your WSL ~/.codex/config.toml by default
• setting is visible in the extension gear icon dropdown, and automatically triggers a restart when you toggle, so we can ensure it has taken effect

[ThoughtPhotography]

0.5.23 is out with a couple fixes here:

Any details on versions 0.5.24-27?

Btw, it would be great if updates were published simultaneously to OpenVSX (marketplace used by VSC forks like Cursor).
The last version is 0.5.20 so users of other IDEs are getting updates.

MS also removed the VSIX download option from marketplace (which OpenVSX has)

I'm sure you'd agree this update process is far from ideal:

• Check Marketplace for new version.
• Open VSC, navigate to Codex extension page.
• Use gear icon to download VSIX (option only appears when the extension isn't installed!)
• Manually install VSIX in Cursor.
• Rinse/repeat for every update.

[dylan-hurd-oai]

@ThoughtPhotography thanks for flagging - historically we have not published pre-releases to OpenVSX due to long caching times. 0.5.20 was a mistake in our process, but we're actively reconsidering this policy.

[dylan-hurd-oai]

@ThoughtPhotography no update on official stance yet but I've also uploaded 0.5.33 (see below) to Open VSX. Propagation here takes longer than VS Code Marketplace, but you should see it in a few hours.

[dylan-hurd-oai]

0.5.30 and 0.4.30 are out:

• We've renamed the setting to our stable setting name chatgpt.runCodexInWindowsSubsystemForLinux to make the setting clearer in the VS Code Settings page. Apologies for the thrash - the description at the top has been updated.

• You can update the setting from within the extension under IDE

• Updating either will automatically reload the window and restart Codex with the updated configuration

We're continuing to iterate on this setup, so please keep the feedback coming!

[Kbediako]

Thanks Dylan, this makes it nice a clear. Random Q, are people outside of oai able to contribute?

[dylan-hurd-oai]

The VS Code extension is not currently open source, but we welcome contributions to openai/codex! Please see our Contribution guidelines to get started.

[infectiousstupidity]

1. Clicking "Open config.toml" on both "MCP settings" and "Codex settings" does nothing. I am able to find the config.toml inside WSL.

---

2. I also get the same error as someone above "[warning] CLI: codex_core::codex: MCP client for context7 failed to start: No such file or directory (os error 2)".

config.toml:

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
startup_timeout_ms = 40_000

---

3. The rate limits are buggy. It'll show e.g 71% of the weekly cap at one time, then 15 minutes later it'll suddenly show 49%.

---

Win 11 23H2, WSL2 with Codex extension pre-release version 0.5.31.

VS Code Insiders
Version: 1.106.0-insider (user setup)
Commit: a24e4c509a43ed2fed08fe6e65c9f26d89c81c75
Date: 2025-10-24T22:13:46.333Z
Electron: 37.7.0
ElectronBuildId: 12597478
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.22631

[dylan-hurd-oai]

Thanks for the detailed report! Addressing these in order:

1. This should be fixed on the latest pre-release, 0.5.33. We open the config.toml corresponding to your current environment
2. We're definitely seeing some bugs with MCP inside WSL via the extension, we're going to continue shipping improved support here.
3. Unrelated to WSL, but a real bug nonetheless! Also fixed in 0.5.33.

[infectiousstupidity]

Updated to the latest pre-release, but still unable to open the config.toml file in any way via the UI.

[janpio]

Same problem with config.toml with 0.5.33 here. Clicking Open config.toml in WSL environment does nothing.
(VS Code started from Windows with Windows path, only using the WSL option to make it use WSL for commands.)

[dylan-hurd-oai]

0.5.33 is out with a few more fixes!

• Better support for preserving PATH vars
• Fix for “Error starting conversation” in new Codex VS Code extension when initializing a chat #2841 - Windows machines with Git Bash and not WSL should no longer error
• For users that are new to this feature, we've added clearer setup instructions

[ysun]

Dear Sir,
Please take a look at how the Codex extension handles network proxies in WSL. This issue has been troubling me for quite a while.

I need to use a network proxy to access the internet — I believe this is the case for many companies as well. When I remote into other physical machines, Codex works fine. However, only in WSL, even with the same network settings and after trying many methods, Codex still cannot access the network.

In contrast, Copilot has never had this issue — as long as I configure the network proxy correctly in VS Code, it works perfectly.

There used to be a workaround for this problem, but it no longer works in version 0.4.31 or 0.5.33.
#2939 (comment)

Please help fix this issue. Thanks!

Thanks

[ysun]

I got some finding, Codex can not recognize socks5 type proxy. By transfering socks5 to http the W/A still working for me now.

[dylan-hurd-oai]

@ysun I believe the underlying issue should be fixed in 0.4.34 - the extension now reads from VS Code's http.proxy configuration. for both Windows Native and WSL mode. Please test it out and let us know if you're seeing issues.

[dylan-hurd-oai]

0.4.34 is out! All the above fixes from 0.5.33, plus some additional bug fixes. Thank you all for your feedback during this time - we appreciate your continued feedback