Codex Desktop WSL-native mode hides Chrome bridge tool and passes Windows attachment paths to Linux agent

What issue are you seeing?

After enabling WSL-native Codex execution with:

[desktop]
runCodexInWindowsSubsystemForLinux = true

Codex correctly runs shell commands inside WSL and avoids repeated Windows wsl.exe launches. However, two Windows-side integrations regress:

1. The normal Chrome bridge becomes unavailable in WSL-native sessions.
2. Local image attachments are passed to the Linux agent as raw Windows paths like C:\Users\...\AppData\Local\Temp\...png, causing No such file or directory.

Environment

• Codex Desktop version: 26.623.13972.0 / plugin runtime observed as 26.623.101652
• Platform: Windows 11 + WSL2 Ubuntu
• Shell after switch: /bin/bash
• Codex app server after switch:

``text
/mnt/c/Users/zhuqi/.codex/bin/wsl/.../codex app-server --analytics-default-enabled
``

Reproduction steps

1. On Windows with WSL2 Ubuntu, configure:

``toml
[desktop]
runCodexInWindowsSubsystemForLinux = true
``

1. Restart Codex Desktop.

1. Open a WSL-backed Codex session.

1. Ask Codex to use the normal Chrome bridge against an existing signed-in Chrome tab.

1. Observe that the Chrome plugin instructions require mcp__node_repl__js, but tool discovery does not expose that tool.

1. Attach or paste an image from Windows clipboard.

1. Observe Codex receives a path like:

``text
C:\Users\zhuqi\AppData\Local\Temp\codex-clipboard-....png
``
and fails to read it inside WSL.

Expected behavior

• In WSL-native Codex mode, WSL repo commands should run inside Linux.
• The trusted Chrome bridge should still be available, or Codex should provide a supported Windows-side bridge path.
• Windows local attachment paths should be translated before being handed to a Linux agent, e.g.:

``text
C:\Users\zhuqi\AppData\Local\Temp\file.png
`
to:
`text
/mnt/c/Users/zhuqi/AppData/Local/Temp/file.png
``

Actual behavior

• mcp__node_repl__js is not exposed in the WSL-native session, so Chrome bridge setup cannot proceed.
• The Chrome plugin files exist and node_repl.exe is running, but the required tool is unavailable to the agent.
• Windows attachment paths fail inside Linux until manually translated to /mnt/c/....

Evidence collected

• Chrome plugin enabled in Windows config:

``toml
[plugins."chrome@openai-bundled"]
enabled = true
``

• WSL-native mode enabled:

``toml
runCodexInWindowsSubsystemForLinux = true
``

• node_repl.exe observed running under the WSL-backed Codex app server.

• Chrome plugin files present:

``text
/mnt/c/Users/zhuqi/.codex/plugins/cache/openai-bundled/chrome/26.623.101652/scripts/browser-client.mjs
``

• Tool discovery did not expose mcp__node_repl__js; it returned unrelated tools.

• Image attachments exist at translated paths and are valid PNGs, but raw C:\... paths fail inside WSL:

``text
/mnt/c/Users/zhuqi/AppData/Local/Temp/codex-clipboard-ccc83cfc-7979-44f7-a959-6f6407fb09c2.png
/mnt/c/Users/zhuqi/AppData/Local/Temp/codex-clipboard-389777c7-8916-4676-ae60-b769833139dd.png
``

• Screenshots from the affected session show:
• Chrome bridge unavailable after WSL-native/interruption state.
• Local image path read failure from raw C:\... path.

Why this matters

Users on Windows + WSL need WSL-native mode to avoid WSL instability from many repeated Windows-side wsl.exe launches. But switching to WSL-native mode currently breaks workflows that depend on signed-in Chrome state, browser verification, clipboard images, and Windows attachment paths.

The current workaround is painful: switch between WSL-native mode for repo work and Windows-hosted mode for Chrome/attachment-heavy work, restarting Codex each time.