›_ Codex Issues
Codex Issues / #33965

Windows Desktop does not surface a healthy WSL stdio MCP server

Open 💬 2 comments Opened Jul 18, 2026 by TeaShaman-cyber
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Windows Desktop does not surface a healthy WSL stdio MCP server

Summary

On Windows, Codex Desktop did not expose the tools of a healthy stdio MCP
server launched through wsl.exe, although the same configuration was enabled
in codex mcp list and the exact server command completed a full MCP protocol
probe. This resembles the existing WSL spawn-bridge reports, but the server in
this reproduction is Docker-backed and does not require Node or Python on the
Windows host.

Environment

  • Codex Desktop Windows: 26.715.3651.0
  • Codex CLI: 0.144.1
  • WSL distribution: Ubuntu 24.04
  • Docker Desktop engine: 29.6.1
  • MemPalace container: 3.5.0

Sanitized configuration

[mcp_servers.mempalace]
command = "wsl.exe"
args = ["-d", "Ubuntu-24.04", "--", "docker", "run", "-i", "--rm",
        "-v", "theseus-mempalace-clean:/data", "theseus-mempalace:pilot"]
enabled = true
startup_timeout_sec = 60
tool_timeout_sec = 120

Evidence

  1. codex mcp get mempalace reported the server as enabled using stdio.
  2. Running the exact launcher independently completed MCP initialize, then

notifications/initialized, then tools/list.

  1. The response identified MemPalace 3.5.0 and returned 36 tools.
  2. In the running Desktop task, no mempalace_* tools were surfaced, while

other configured MCP tools were available.

  1. A bounded Windows process/network snapshot found Codex Desktop, its

code-mode host, Docker Desktop, and expected local service listeners alive;
it did not indicate a Docker or WSL outage.

Candidate workaround

The same container and volume pass the identical full MCP probe when launched
with native docker.exe instead of wsl.exe:

[mcp_servers.mempalace]
command = "docker.exe"
args = ["run", "-i", "--rm", "-v", "theseus-mempalace-clean:/data",
        "theseus-mempalace:pilot"]

This removes only the Desktop-to-WSL process hop. It preserves the volume and
MCP server. Desktop reload verification is still pending after a full restart,
so this is a candidate workaround rather than a confirmed product fix.

Expected behavior

When codex mcp list reports an enabled stdio server and the exact command
successfully completes initialize and tools/list, Codex Desktop should
surface the server tools or provide a visible startup error with captured
stderr.

Related reports

  • #21147: Windows Desktop WSL mode launches a Windows app-server path.
  • Discussion #5471: MCP servers work from WSL CLI but are not detected in the

Windows IDE/WSL bridge.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33599

Powered by Codex Action

TeaShaman-cyber · 21 days ago

Update — 2026-08-06: Docker-backed Streamable HTTP works in Desktop; stdio remains invisible

I ran a controlled A/B comparison using the same read-only Sonar MCP server, the same Docker image, the same named DuckDB volume, and the same AutoMem-backed index.

Baseline: Docker-backed stdio

The stdio route completed the MCP protocol smoke test outside Desktop:

  • initialize: passed
  • notifications/initialized: passed
  • tools/list: passed
  • tools returned:
  • sonar_status
  • sonar_refresh
  • sonar_preflight

However, after a full Codex Desktop restart, none of the sonar_* tools appeared in the running Desktop task.

Candidate workaround: localhost Streamable HTTP

I then exposed the same container service through a localhost-only Docker port:

http://127.0.0.1:8791/mcp

The container still uses the same named DuckDB volume and the same read-only FastMCP tools.

The direct Streamable HTTP protocol smoke passed:

  • MCP initialize completed;
  • tools/list returned exactly the three Sonar tools;
  • sonar_status returned OK;
  • the index contained 305 documents, 2611 memory edges, 9 federation nodes, and 11 federation edges;
  • a selective sonar_preflight returned status: OK, with no conflicts and no gaps.

After restarting Codex Desktop with the project-scoped HTTP profile, the tools were surfaced and callable in the Desktop task:

mcp__theseus_sonar_http__sonar_status
mcp__theseus_sonar_http__sonar_refresh
mcp__theseus_sonar_http__sonar_preflight

A live sonar_status call and a selective sonar_preflight call both succeeded.

Updated isolation

This comparison keeps the backend, image, volume, and MCP tool implementation constant while changing only the Desktop-facing transport:

Docker stdio MCP:
  direct protocol: PASS
  Desktop tools:   NOT SURFACED

Docker Streamable HTTP MCP:
  direct protocol: PASS
  Desktop tools:   SURFACED AND CALLABLE

This narrows the failure to the Windows Desktop stdio/process-chain or stdio tool-injection path. It also shows that a localhost-only Streamable HTTP route is a working practical workaround for this reproduction.

The global Codex configuration was not modified. The working HTTP profile is project-scoped and binds only to 127.0.0.1.

Related reports:

  • #33599 — Desktop tasks can silently omit healthy MCP tools from the task tool surface.
  • #34719 — post-compaction tool-manifest hydration can lose configured MCP/app tools.

The current reproduction is not limited to post-compaction recovery: the stdio-vs-HTTP comparison was performed after a full restart.