Codex app on Windows can not call MCP on WSL

Open 💬 2 comments Opened Mar 6, 2026 by youtonghy

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.305.950.0

What subscription do you have?

Team

What platform is your computer?

Windows 11 x64

What issue are you seeing?

When I choose WSL as the Agent environment, I cannot call any added MCP servers. It can be started and called normally in CLI mode. Codex currently believes that the automatic testing indicates an exception in the WSL/Windows workspace bridging, which causes mcp not to be correctly injected into the thread. Using the Windows native agent environment has no problem.

What steps can reproduce the bug?

Use windows native agent environment

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

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

#13549
#13556

Powered by Codex Action

Lianye-Scythe · 2 months ago

Additional reproduction report

I can reproduce the same issue on Windows with Codex Desktop running the agent in WSL mode.

Environment

Codex Desktop: 26.609.30741
Codex CLI/runtime reported by codex doctor: 0.140.0-alpha.2 (linux-x86_64)
Host OS: Windows 11 x64
Agent environment: WSL2 Ubuntu 24.04.4 LTS
WSL kernel: 6.6.87.2-microsoft-standard-WSL2
MCP servers tested:
chrome-devtools-mcp@latest
@upstash/context7-mcp

What happens

When the MCP servers are configured to launch through WSL-native Node/npm, Codex can read the MCP config and the MCP servers themselves work, but Codex Desktop does not expose their tools in the conversation/tool list.

Example WSL-native config shape:

[mcp_servers.chrome-devtools]
command = "/home/<user>/.nvm/current/bin/npx"
args = ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics", "--no-performance-crux", "--headless"]
cwd = "/home/<user>"
startup_timeout_sec = 40

[mcp_servers.context7]
command = "/home/<user>/.nvm/current/bin/npx"
args = ["-y", "@upstash/context7-mcp"]
cwd = "/home/<user>"
startup_timeout_sec = 20

[mcp_servers.context7.env]
CONTEXT7_API_KEY = "<redacted>"

With this setup:

codex mcp list shows both servers as enabled.
codex doctor reports config parse OK and MCP servers present.
Starting the same commands manually from WSL works.
A direct MCP SDK stdio client can initialize and tools/list successfully:
chrome-devtools returns 29 tools, including click, evaluate_script, get_network_request, etc.
context7 returns 2 tools: resolve-library-id and query-docs.
However, after restarting Codex Desktop and opening a new conversation, those tools are not exposed to the model. tool_search does not find mcp__chrome_devtools or mcp__context7 tools.

Workaround that works

If I change the same MCP servers back to a Windows launcher, Codex Desktop exposes the tools correctly.

Working config shape:

[mcp_servers.chrome-devtools]
command = "/mnt/c/nvm4w/nodejs/node.exe"
args = ['C:\nvm4w\nodejs\node_modules\npm\bin\npx-cli.js', "-y", "chrome-devtools-mcp@latest", "--no-usage-statistics", "--no-performance-crux", "--headless"]
cwd = "/mnt/c/Users/<user>"
startup_timeout_sec = 40

[mcp_servers.context7]
command = "/mnt/c/nvm4w/nodejs/node.exe"
args = ['C:\nvm4w\nodejs\node_modules\npm\bin\npx-cli.js', "-y", "@upstash/context7-mcp"]
cwd = "/mnt/c/Users/<user>"
startup_timeout_sec = 20

[mcp_servers.context7.env]
CONTEXT7_API_KEY = "<redacted>"

After restarting Codex Desktop with the Windows launcher config:

mcp__context7.resolve_library_id is visible and callable.
mcp__chrome_devtools.list_pages is visible and callable.
chrome-devtools returns the selected about:blank page as expected.

Interpretation

This looks like the MCP server process and WSL Node/npm are fine. The failure appears to be specific to Codex Desktop's tool injection / MCP launcher path when the configured stdio MCP command is WSL-native. Using a Windows executable as the launcher is currently a reliable workaround.