›_ Codex Issues
Codex Issues / #40875

Add Windows + WSL2 smoke tests for Codex Desktop thread start/resume regressions

Open 💬 5 comments Opened Aug 26, 2026 by taobaibais
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Problem

The current Codex Desktop Stable 26.820.x regression breaks starting and resuming WSL-hosted threads with:

failed to load configuration: invalid transport in `mcp_servers.codex_app`

This is already tracked in #40819 and #40715.

The concerning part is that this regression appears to affect a basic, high-value workflow:

  • Windows 11
  • WSL2 workspace
  • Codex Desktop configured to run the agent in WSL
  • start a new thread
  • resume an existing thread

A minimal smoke test covering this path should have failed immediately before the Stable release shipped.

Request

Please add release-gating regression coverage for the Codex Desktop -> WSL execution path, at minimum:

  1. Launch Codex Desktop on Windows with WSL2 enabled.
  2. Open a repository stored inside the WSL filesystem.
  3. Start a new Codex thread in the WSL agent environment.
  4. Resume an existing WSL-hosted thread.
  5. Verify that Desktop-managed MCP configuration is valid and contains a usable transport before it is passed to the WSL app-server.
  6. Verify that a failure caused by Desktop-generated runtime configuration does not incorrectly tell the user to fix config.toml.

Why this matters

For users who intentionally keep their repositories and toolchains inside WSL, switching the agent environment to Windows native is not an equivalent workaround. A regression in the Desktop -> WSL launch path can completely block development work.

The current incident also produced a misleading error message pointing at the user's config.toml, even though reports indicate the invalid mcp_servers.codex_app entry is generated by Desktop at runtime.

Expected outcome

A Stable release should not ship if basic Windows + WSL2 thread start/resume smoke tests fail. Please add automated or release-check coverage for this path so regressions like #40819 are caught before rollout.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 day ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #40715
  • #40819
  • #40829
  • #40732

Powered by Codex Action

taobaibais · 1 day ago

I can confirm the same regression on Windows 11 + WSL2 with Codex Desktop 26.820.x. Both creating new chats and resuming existing chats fail with invalid transport in mcp_servers.codex_app, while my user config.toml has no mcp_servers.codex_app entry. WSL is my required development environment, so switching the agent to Windows-native is not a viable workaround for me. This is a complete work blocker.

taobaibais · 1 day ago

Given that this regression completely blocks a supported development workflow for paying users, OpenAI should also consider compensation for affected accounts. At minimum, users impacted by the WSL outage should receive additional/banked usage resets (or equivalent credits) for the period in which Codex Desktop was unusable in their required environment. We are paying for access to this service, and a release regression that prevents all new/resumed WSL chats from working should not consume users' paid usage window without remedy.

tm1nus · 1 day ago

really feel disappointed when codex crashed because of wsl.
my work have to be delayed

taobaibais · 1 day ago

This incident is also a good example of why release-gating WSL smoke tests matter. Beyond the eventual fix, could OpenAI please acknowledge the current outage publicly? Multiple issues, many confirmations, and a known work-blocking Stable regression have accumulated without a visible maintainer response so far.