Repository navigation
Chrome plugin writes invalid WSL-style path in Windows native host manifest #28956
Description
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
Activity
github-actions commentedon Jun 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xiaohanzhu commentedon Jun 19, 2026
This bug is specifically related to WSL and native hybrid environment on windows
julesLubrano commentedon Aug 15, 2026
Still reproducible on 2026-08-15 with a newer Windows build.
Environment:
Verified behavior:
[marketplaces.openai-bundled].sourcevalue is written as a WSL path matching/mnt/c/Users/<user>/.codex/....chrome/latestlink resolves to a doubled path matching/mnt/c/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/chrome/<version>.extension-host-config.jsonis absent from the resolved host directory.agent.browsers.get("chrome")returnsBrowser 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 stalechrome/latesttarget.zemeng5208 commentedon Aug 15, 2026
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/latestresolves to an invalid target, plus Chrome Native Host state that no longer points to a usable Windows-nativeextension-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/latestpointer, and Chrome Native Host manifest/registry/v2 registration consistency. It does not patch or take ownership ofC:\Program Files\WindowsApps, and it does not bypass browser/security policy.Important limitation: if the Desktop runtime is actively re-writing
[marketplaces.openai-bundled].sourceorchrome/latestback 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.