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.)

[infectiousstupidity]

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.

Still can't open config.toml when WSL is enabled. The only way I was able to open it was if I used VS Code "Connect to WSL" first, which brings a whole different set of unrelated problems when relying on certain tools that require full GUI compatibility (I'm looking at you, WXT). Opening it with "Connect to WSL" also made all the MCP servers work.

Am I doing something wrong? Is it not supposed to work by just enabling "IDE settings" -> "Run in WSL"?

[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

[janpio]

Current 0.5.36 seems to hang when loading past chats, which makes the extension completely unusable.

[infectiousstupidity]

Just wanted to say that I'm not affected by this issue at all, I can load all previous chats, both local and cloud just fine.

I'm also on 0.5.36 and VS Code Insiders.

Version: 1.106.0-insider (user setup)
Commit: 402271f5deb7fc29b000463cfa525fc8c03fb7d7
Date: 2025-11-06T05:02:32.118Z
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

[janpio]

0.5.37 fixes the endless spinner by replacing it with a crash:

2025-11-07 21:23:57.034 [error] unable to parse stdout from codex app-server: SyntaxError: Unexpected token 'T', "T h e r e "... is not valid JSON
2025-11-07 21:23:57.034 [error] unable to parse stdout from codex app-server: SyntaxError: Unexpected token ' ', " " is not valid JSON
2025-11-07 21:23:57.034 [error] unable to parse stdout from codex app-server: SyntaxError: Unexpected token ' ', " E r r o r"... is not valid JSON
2025-11-07 21:23:57.034 [error] unable to parse stdout from codex app-server: SyntaxError: Unexpected token ' ', " " is not valid JSON
2025-11-07 21:23:57.034 [error] [CodexMcpConnection] Codex process fatal error: Codex process errored: Codex app-server process exited unexpectedly (code=4294967295, signal=null), signal=null, exitCode=4294967295
2025-11-07 21:23:57.034 [error] [CodexWebviewProvider] fatal error: Codex process errored: Codex app-server process exited unexpectedly (code=4294967295, signal=null)
2025-11-07 21:23:59.020 [warning] Attempted to send app-server message but stdin is destroyed: {"id":"CodexWebviewProvider.webview:d838df52-a1f9-470e-b3e0-8b2855a6fbc8","method":"listConversations","params":{"pageSize":20,"cursor":null,"modelProviders":null}}
2025-11-07 21:23:59.020 [error] [CodexMcpConnection] Codex process fatal error: Codex process errored: Codex process is not available, signal=null, exitCode=null
2025-11-07 21:23:59.020 [error] [CodexWebviewProvider] fatal error: Codex process errored: Codex process is not available
2025-11-07 21:23:59.022 [warning] Attempted to send app-server message but stdin is destroyed: {"id":"CodexWebviewProvider.webview:d8b2fa50-159f-4151-8380-94a11388aceb","method":"getAuthStatus","params":{"includeToken":false,"refreshToken":false}}
2025-11-07 21:23:59.022 [error] [CodexMcpConnection] Codex process fatal error: Codex process errored: Codex process is not available, signal=null, exitCode=null
2025-11-07 21:23:59.022 [error] [CodexWebviewProvider] fatal error: Codex process errored: Codex process is not available
2025-11-07 21:23:59.091 [warning] Attempted to send app-server message but stdin is destroyed: {"id":"CodexWebviewProvider.webview:08eeec23-493b-4751-84e0-30acdac9c5d2","method":"getAuthStatus","params":{"includeToken":false,"refreshToken":false}}
2025-11-07 21:23:59.091 [error] [CodexMcpConnection] Codex process fatal error: Codex process errored: Codex process is not available, signal=null, exitCode=null
2025-11-07 21:23:59.091 [error] [CodexWebviewProvider] fatal error: Codex process errored: Codex process is not available

This happens when running VSCode in Windows directly, not WSL. Project folder is also in C:\Projects.

Version: 1.105.1 (user setup)
Commit: 7d842fb85a0275a4a8e4d7e040d2625abbf7f084
Date: 2025-10-14T22:33:36.618Z
Electron: 37.6.0
ElectronBuildId: 12502201
Chromium: 138.0.7204.251
Node.js: 22.19.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26100

Via VSCode and WSL, project loaded via /mnt/c/Projects/, it works as expected.

[Lyn6969]

I'm experiencing the exact same issue. The plugin only starts working when I disable WSL mode. It doesn't work even after a complete uninstall and reinstall. What is the root cause of this problem?

[dylan-hurd-oai]

Hi folks - we've addressed a significant number of issues in 0.4.39 / 0.5.39 here. Please upgrade and let us know if you're still affected.

[janpio]

I can confirm that 0.5.39 now works both in (stable) VS Code under Windows directly and in VS Code in WSL again for me.

[ThoughtPhotography]

I'm trying to enable web search, but the option to open the config file in WSL doesn't do anything (the file opens fine in non-WSL mode)

[janpio]

I think it works when you open your project/workspaca via WSL, but not when it is opened via Windows. Bottom left of VS Code it should say "WSL: Ubuntu" or similar.

[ThoughtPhotography]

I think it works when you open your project/workspaca via WSL, but not when it is opened via Windows. Bottom left of VS Code it should say "WSL: Ubuntu" or similar.

I'm not seeing anything like that, however WSL mode for the extension works so I assume it's fine.
The CLI in WSL doesn't have a slash command to open/edit the config either, making a false assumption that Windows users are going to have sufficient linux knowledge to do everything manually when it's far more likely they're using WSL because the native version of codex isn't very good.

Even when running what I assuming is the correct command in WSL to modify the config there's no indication whether anything was changed. 🤷‍♂️
codex -c web_search_request="true"

Something so basic shouldn't be this frustrating.

[infectiousstupidity]

Yes, this is the only way I managed to get it to work - to run VS Code in WSL, but this ends up breaking other tools (GUI tools specifically) that don't play nice in WSL currently.

It would be nice to get some clarification on what is actually supposed to be possible.

1. When we run the extension with "IDE settings" -> "Run in WSL" enabled should we be able to open the config.toml via the "Open config.toml in WSL environment" button? Or is this only supposed to work if we run VS Code via "Connect to WSL"? mode?
2. Depending on the answer to 1, how are we supposed to configure MCP servers? Currently I am completely unable to get MCP servers to work unless I run VS Code via "Connect to WSL".

I spent hours trying to get MCP servers to work while sifting through countless GitHub issues and discussions, testing all kinds of things, but nothing worked, so I've given up.

[janpio]

I'm not seeing anything like that, however WSL mode for the extension works so I assume it's fine.

@ThoughtPhotography That's a different thing unfortunately, the WSL mode in the VS Code extension is just a flag that instructs Codex to use certain commands or not. For them to work, including opening the config.toml, your VS Code currently seems to have to be in a specific state. Here are some instructions on how to get there: https://code.visualstudio.com/docs/remote/wsl-tutorial (One option: Open WSL, navigate to your project folder, type ' code .' and your VS Code will be started in the correct mode)

It would be nice to get some clarification

@infectiousstupidity I can't clarify, but my understanding is indeed that Codex on Windows is to be used in a WSL context, which means that VS Code should be in "Connect to WSL" mode and work on a folder in WSL space. (Semi source for this: https://developers.openai.com/codex/windows)

[infectiousstupidity]

" When this flag is set, the extension automatically launches the agent inside WSL"

To me this reads like only the agent launches in WSL, not that VS Code itself must be ran in WSL. Hope we can get some clarifications soon.

[ThoughtPhotography]

According to the OP on X, GPT-5.1 is the best of the new models for Codex on Windows.
Let's hope that means it's reliable without WSL.

[kiptaylor]

Having insane difference in codex from this morning to the new update, tasks taking 40 + mins on extension to think about the problem, when yesterday it was mere minuetes.

[ThoughtPhotography]

That sounds promising!
Are you still using "Run Codex In Windows Subsystem For Linux"?

[kiptaylor]

Yes, should i turn that off ?

[kiptaylor]

As it literally will not work with newest 2 updates

[ThoughtPhotography]

I didn't test with WSL mode, but it's been working fairly well without.
I get an "❌Oops, an error occurred" screen sometimes when it's responding, but that's probably just an extension bug. The response is usually there when I re-open the chat.

My main complaint is I often have to prod the model to do the actual work.
Agent (full access) is acting like Chat mode ("here's all the things you need to do yourself" 🙄)

[ThoughtPhotography]

I figured out how to modify with WSL config.toml

It's at this path (Windows Explorer):
Network\wsl$\Ubuntu\home\[username]\.codex
AKA
\\wsl.localhost\Ubuntu\home\[username]\.codex

The extension should be able to open it from the menu using the correct path. 🤷‍♂️

[etraut-openai]

Good catch. If the extension isn't opening the correct path to config.toml in WSL mode, that's a bug. Could you file a bug report in the issue tracker? Thanks!

[ThoughtPhotography]

Will do.

[infectiousstupidity]

I never had any issues editing the WSL config.toml via WSL itself - the problem for me was that it never opened via the extension settings + no MCP servers never work no matter what I tried (tested all possible solutions I found on github). The MCP servers only worked when I opened VS Code itself in WSL mode, not just the extension.

[dylan-hurd-oai]

Hi folks - thanks for all the discussion here. Going to cross-post this announcement for visibility:

For the past two weeks, we've been testing and refining a new Windows-native sandbox implementation for the Codex CLI and IDE extension. The latest versions of the CLI and extension incorporate the latest bug fixes for this feature. The new Windows sandbox is still considered "experimental", but we think it's ready for broader use, and we welcome you to give it a try. For more details, refer to this documentation. With the new sandbox enabled, you should see far fewer approval requests. We also released new model: GPT-5.1-Codex-Max. In addition to being more token efficient and able to solve longer-horizon problems, it also has improved support for Windows code generation and tool usage.

Instead of using "Run in WSL", you can now try Agent mode in the experimental sandbox on Native Windows. We'd love your feedback in #6065

[yaronelh]

The bug appears to be in the Codex IDE Extension’s WSL process-spawning / sandbox bridge, which prevents MCP servers from being started or detected when using the IDE interface, despite working correctly via the CLI.

Maybe this AI summary will be helpful

Environment

• OS: Windows + WSL (Ubuntu)
• Codex CLI: latest
• Codex VS Code IDE Extension: latest
• MCP server tested: chrome-devtools-mcp
• Node installations tested:
  • nvm (Node v22.x)
  • system install via apt (Node v18.x)

Expected behavior

MCP servers defined in ~/.codex/config.toml inside WSL should be detected and available when Codex is launched via the VS Code IDE extension in a WSL workspace.

Actual behavior

When Codex is launched via the VS Code IDE extension in WSL, it always reports “no MCP servers available”, even though the same MCP servers work when started manually or when using the Codex CLI directly in WSL.

What works

• MCP servers start and run correctly when launched manually inside WSL:

  npx -y chrome-devtools-mcp@latest --autoConnect --channel=canary

• MCP servers are detected and usable when running Codex CLI directly from a WSL terminal.
• Node, npm, and npx are functional in WSL (verified via both nvm and system installs).
• ~/.codex/config.toml is correctly located and read inside WSL.

What was tried / ruled out

Config & paths

• Corrected cwd to Linux paths (no UNC paths)
• Removed cwd entirely
• Verified config file path: ~/.codex/config.toml inside WSL

Node / npx resolution

• Verified npx works interactively
• Hard-coded MCP command to:
  • nvm path (/home/.../.nvm/.../npx)
  • system path (/usr/bin/npx)
• Installed Node/npm system-wide via apt

Environment / restart

• Restarted VS Code completely
• Shut down WSL from Windows (wsl --shutdown)
• Reopened WSL workspace

MCP sanity checks

• Tested a zero-dependency MCP server:

  bash -lc "echo MCP_STARTED; cat"

• Confirmed MCP spawning works when Codex is run manually
• Confirmed NOT related to:
  • Proxies / DNS
  • nvm misconfiguration
  • MCP server implementation
  • Incorrect config location

Key observation

MCP servers work in WSL when Codex is run via the CLI, but are never detected when Codex is launched via the VS Code IDE extension in WSL.

This strongly suggests an issue or limitation in how the Windows-native IDE extension sandbox spawns MCP server processes when targeting WSL, rather than a configuration or environment problem.

Conclusion

At this point, environment and configuration causes have been exhausted. The remaining issue appears to be in the Codex IDE Extension’s WSL process-spawning / sandbox bridge, which prevents MCP servers from being started or detected when using the IDE interface, despite working correctly via the CLI.

[etraut-openai]

@yaronelh, thanks for posting. Could you please create a bug report with this information so we can track it?

[yaronelh]

I think I wrote all the necessary information. If you can open the bug report that would be better. I don't have time for separating everything into fields for a new report