Chrome plugin writes invalid WSL-style path in Windows native host manifest

Open 💬 4 comments Opened Jun 18, 2026 by xiaohanzhu

💡 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)?

Version 26.616.30709, Windows Codex Extension Version v1.1.5

What subscription do you have?

Pro

What platform is your computer?

Windows, using codex in native Windows UI with environment set to WSL

What issue are you seeing?

Summary

Codex Chrome plugin cannot attach to Chrome on Windows because the Chrome Native Messaging Host manifest points to a WSL-style path that Windows cannot resolve.

The Codex Chrome extension is installed and enabled, but Codex sees zero controllable Chrome sessions and reports:

Browser is not available: extension

### What steps can reproduce the bug?

Reproduction Steps
Install/reinstall the Codex Chrome plugin from Codex Plugins.
Install/enable the Codex Chrome Extension in Chrome.
Use a WSL workspace where plugin cache paths are under /mnt/c/....
Ask Codex to use Chrome, e.g. chrome open united.com.
Codex fails to attach with:
Browser is not available: extension

### What is the expected behavior?

What I Expected
After installing the Chrome plugin and Codex Chrome Extension, Codex should attach to Chrome and open/control tabs.
What Happened
The extension is installed/enabled and the native host manifest exists, but Chrome cannot start the native host because the manifest path is invalid on Windows.
Manifest file:
C:\Users\<user>\AppData\Local\OpenAI\extension\com.openai.codexextension.json
The manifest currently contains this native host path:
\\mnt\\c\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe
Windows cannot resolve that path:
NativePathExists=false
But the Windows-equivalent path does exist:
C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe
WindowsEquivalentExists=true
Reproduction Steps
Install/reinstall the Codex Chrome plugin from Codex Plugins.
Install/enable the Codex Chrome Extension in Chrome.
Use a WSL workspace where plugin cache paths are under /mnt/c/....
Ask Codex to use Chrome, e.g. chrome open united.com.
Codex fails to attach with:
Browser is not available: extension
Diagnostics Already Checked
Chrome installed: yes
Chrome running after plugin launch: yes
Codex Chrome Extension installed: yes
Codex Chrome Extension enabled: yes
Selected Chrome profile: Profile 1
Native host manifest exists: yes
Manifest allowed origin matches extension ID: yes
Native host manifest path exists from Windows: no
Correct Windows-equivalent executable path exists: yes
Codex-visible browser sessions: zero
Notes
This does not appear to be a conflict with another Chrome extension. The concrete failure is that the native host manifest uses a WSL-style path instead of a Windows-native executable path.

### Additional information

Environment
OS: Windows with WSL workspace
Codex app: Windows app, observed package version 26.611.8604.0
Chrome plugin cache version: 26.611.62324
Codex Chrome Extension version: 1.1.5_0
Chrome version: 149.0.7827.115
Chrome profile: Profile 1

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

#28950

Powered by Codex Action

xiaohanzhu · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Windows: Chrome plugin install fails to create com.openai.codexextension Native Messaging Host #28950 _Powered by Codex Action_

This bug is specifically related to WSL and native hybrid environment on windows

julesLubrano · 13 days ago

Still reproducible on 2026-08-15 with a newer Windows build.

Environment:

Codex Desktop for Windows (MSIX 26.810.7004.0)
Chrome bundled plugin 26.727.51351
Windows x64
WSL-backed workspace

Verified behavior:

The Windows-side [marketplaces.openai-bundled].source value is written as a WSL path matching /mnt/c/Users/<user>/.codex/....
The chrome/latest link resolves to a doubled path matching /mnt/c/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/chrome/<version>.
The native-host manifest exists, but the expected adjacent extension-host-config.json is absent from the resolved host directory.
The Chrome extension/plugin files are present, but agent.browsers.get("chrome") returns Browser is not available: chrome.

This strongly suggests that Windows-native path normalization is still not consistently applied when the Desktop task uses a WSL workspace. The installer/runtime should normalize the marketplace source and link target to a real C:\\Users\\<user>\\... path and self-heal an invalid or stale chrome/latest target.

zemeng5208 · 13 days ago

I maintain WinBridge Recovery, an independent Windows recovery tool for Codex Desktop plugin/runtime state: https://github.com/zemeng5208/winbridge-recovery

The new 2026-08-15 reproduction here is a strong match for one of the local states WinBridge is designed to diagnose/recover: Windows-side bundled marketplace/cache drift where chrome/latest resolves to an invalid target, plus Chrome Native Host state that no longer points to a usable Windows-native extension-host.exe/config path.

For this specific case, WinBridge can help check and rebuild the local Windows layer from the already-installed official package: bundled marketplace/cache version state, the chrome/latest pointer, and Chrome Native Host manifest/registry/v2 registration consistency. It does not patch or take ownership of C:\Program Files\WindowsApps, and it does not bypass browser/security policy.

Important limitation: if the Desktop runtime is actively re-writing [marketplaces.openai-bundled].source or chrome/latest back to a WSL-form /mnt/c/... path each time a WSL-backed workspace is opened, that normalization bug is upstream. A local repair may restore a correct Windows-native state temporarily, but I would not expect it to be a permanent fix until Codex stops regenerating the invalid path.

So this looks useful as a diagnostic/recovery path for the broken local cache/native-host state, not as a guarantee that the WSL path-regeneration bug itself is fixed.