Chrome control broken in WSL-agent mode: native-messaging host manifest written with un-translated /mnt/c path (and non-existent 'latest' segment)

Summary

When Codex Desktop is configured to run the agent inside WSL (runCodexInWindowsSubsystemForLinux = true), the Chrome control feature is completely non-functional. The Chrome extension installs and the native-messaging host registers, but the native messaging host manifest is written with un-translated WSL paths, so Chrome can never launch the host. The browser tools silently do nothing.

Environment

• OS: Windows 11 + WSL2 (Ubuntu)
• Codex Desktop: 26.623.31921 (MSIX package OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0)
• Setting: runCodexInWindowsSubsystemForLinux = true (agent runs in WSL; CODEX_HOME = C:\Users\<user>\.codex)
• Chrome extension "Codex" (hehggadaopoacecdllhhajmbjkdcmajg) installed and present; native host com.openai.codexextension registered in HKCU\Software\Google\Chrome\NativeMessagingHosts.

Root cause: WSL mount path written into a Windows-consumed manifest

The native messaging host manifest that Chrome actually reads —
C:\Users\<user>\AppData\Local\OpenAI\extension\com.openai.codexextension.json — contains:

{
  "allowed_origins": ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"],
  "name": "com.openai.codexextension",
  "path": "\\mnt\\c\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe",
  "type": "stdio"
}

The path value is broken in two independent ways:

1. WSL mount path not translated to a drive letter. \mnt\c\... is the WSL view /mnt/c/... with forward slashes replaced by backslashes — but /mnt/c was never converted to C:. Chrome is a Windows process, so it resolves \mnt\c\Users\... relative to the current drive root, i.e. C:\mnt\c\Users\..., which does not exist. The correct value should be C:\Users\<user>\.codex\....

1. Non-existent latest version segment. The manifest uses ...\chrome\latest\..., but the only installed version directory is ...\chrome\26.623.31921\.... There is no latest alias/symlink on disk.

The same broken pattern appears in %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json (fields browserClientPath, codexCliPath, extensionHostPath all use \mnt\c\...\latest\...).

The correct, existing files are at:

C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\26.623.31921\extension-host\windows\x64\extension-host.exe
C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\26.623.31921\scripts\browser-client.mjs

Smoking gun

Because a Windows process was handed \mnt\c\..., Windows created a ghost mirror tree at C:\mnt\c\Users\<user>\.codex\..., into which some plugin-appserver binaries (codex.exe, codex-command-runner.exe, codex-windows-sandbox-setup.exe) were actually staged — instead of the real C:\Users\<user>\.codex\plugins\.plugin-appserver\. This confirms the path is being consumed verbatim by Windows-side components that cannot interpret a WSL mount path.

Impact

• Chrome control via the extension is silently 100% broken in WSL-agent mode — no error surfaced to the user; the model's browser actions appear to "do nothing."
• The plugin install is left scattered (real version dir + a bogus C:\mnt\c\... tree), so manual manifest patching is not durable: Codex Desktop regenerates these manifests on launch/plugin-sync and re-introduces the broken paths.

Expected behavior

When the agent runs in WSL, any path written into Windows-consumed artifacts (Chrome native-messaging host manifest, chrome-native-hosts-v2.json) must be translated from the WSL mount form (/mnt/c/...) to a Windows path (C:\...), and must resolve to the concrete installed version directory rather than a non-existent latest alias.

Steps to reproduce

1. Windows + WSL2, Codex Desktop with runCodexInWindowsSubsystemForLinux = true.
2. Enable the chrome@openai-bundled plugin and install the Codex Chrome extension.
3. Ask Codex to control Chrome (e.g. open a page / read a field).
4. Observe: nothing happens. Inspect %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json — the path field is \mnt\c\...\chrome\latest\...\extension-host.exe, which does not resolve.

Suggested fix

In the path-normalization step that emits Windows-side manifests under WSL-agent mode:

• Convert /mnt/<drive>/... → <DRIVE>:\... (don't just swap slashes).
• Resolve the actual installed version directory instead of writing latest.