Multiple Codex Desktop features appear to degrade in Windows-to-WSL agent mode; what is the intended support boundary?

[tompw89]

I am trying to understand the intended support boundary for Codex Desktop when using a WSL-side agent from the Windows Desktop app.

I searched existing issues and Discussions before posting. I found several symptom-specific issues, but I did not find an umbrella Discussion about the broader pattern.

The pattern I am seeing is:

Multiple Codex Desktop features that require Windows-to-WSL coordination appear to fail or degrade in WSL agent mode.

This is not meant as a duplicate bug report, and I am not claiming every WSL Desktop user is affected. The concern is that several separate open issues seem to point at the same class of boundary problem: the Windows Desktop shell, app-server, helper runtimes, browser tooling, MCP launch environment, Git state, and WSL filesystem/config state do not always agree about where execution is happening.

A few examples:

• Windows Codex app + WSL: UNC cwd breaks terminal, Windows config leaks into WSL, and worktrees need a WSL-native CODEX_HOME #18506: Windows Codex app + WSL path/config/home-boundary issues, including UNC cwd, Windows config leaking into WSL, and the need for WSL-native CODEX_HOME.
• Desktop automations on Windows/WSL create automation runs but no rollout materializes, then resume fails with 'no rollout found' #16994 and Codex Desktop automations do not dispatch prompt correctly for WSL workspaces #20415: Desktop automations on Windows/WSL create run/thread state but do not produce a usable rollout or do not dispatch the prompt correctly.
• Windows desktop Summary tab shows false GitHub CLI / PR status errors for WSL repos and logs git watcher ENOENT on .git paths #17991: Desktop Git/PR status can show false errors for WSL repositories, with git watcher failures on WSL-backed .git paths.
• Windows Codex App: Browser Use unavailable because Node REPL tool is not exposed #19365 and Codex Desktop: @Chrome extension is Connected but browser tasks fall back to chrome-devtools isolated profile on Windows #21868: Browser Use / @Chrome integration issues on Windows Desktop, including missing Node REPL tool exposure and fallback to an isolated browser path.
• Windows Desktop: workspace_dependencies feature mismatch persists after local recovery #21505: workspace_dependencies feature/runtime mismatch after local recovery.
• Custom stdio MCP server discovered by /mcp but tools not exposed to Desktop threads #19425 and Codex App disconnects all MCP servers when Playwright MCP returns -32601 for resource template listing #14454: MCP-related Desktop issues where MCP servers/tools are discovered or configured but not exposed cleanly to Desktop threads, or where Playwright MCP behaviour affects MCP availability.
• Codex Desktop should use a project-scoped MCP process pool instead of starting MCP per session #20883: MCP process lifecycle/pooling concerns around Desktop/app-server.

The MCP case is particularly useful as a lower-level example. In one current WSL Desktop setup, a Playwright MCP server was configured in the WSL Codex home, but the Desktop-launched environment resolved npx through Windows paths rather than the intended WSL Node/NVM path. Current source suggests that once an MCP server starts and lists tools successfully, those tools should be exposed directly or via tool search. So missing tools in that setup look more like a launch/readiness/environment problem than a user simply looking in the wrong place.

My question is:

Is WSL agent mode intended to support Desktop features like automations, Browser Use / @Chrome, Git/PR status, workspace dependencies, and custom MCP servers reliably today?

If yes, is there a recommended configuration for Windows Desktop + WSL that avoids these boundary failures?

If no, could the current support boundary be documented more explicitly, so users know when to prefer the WSL CLI over Desktop?

The reason I am asking this as a Discussion rather than opening another issue is that the individual bug reports already exist. The collective impact is the part that seems easy to miss: for Windows users coding primarily inside WSL, these are some of the features that make Desktop attractive over the CLI, so failures across them materially affect the Desktop experience.