›_ Codex Issues
Codex Issues / #24838

Windows: Chrome extension installed and native host registered, but extension backend is unavailable

Open 💬 3 comments Opened May 28, 2026 by KangLiu-GeoAI

Summary

On Windows, the Codex in-app browser works after enabling js_repl and --disable-sandbox, but the Chrome backend remains unavailable even though the Codex Chrome extension is installed, enabled, and the native host registry entry exists.

Expected behavior

agent.browsers.list() should include the Chrome extension backend, and agent.browsers.get("extension") should succeed.

Actual behavior

  • In-app browser (iab) works
  • agent.browsers.list() only returns the in-app browser
  • agent.browsers.get("extension") fails with Browser is not available: extension

Reproduction

  1. Install/enable the Codex Chrome Extension on Windows
  2. Confirm native host manifest and registry are present
  3. Start Codex Desktop and use the Browser/Chrome workflows
  4. Observe that only iab is available in runtime

Environment

  • Codex desktop release: 26.519.81530
  • Windows Store build
  • OS: Windows 10.0.26200
  • Chrome runtime seen in logs: 148.0.7778.97

Verified local state

  • Chrome extension installed and enabled
  • Native host registry exists: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
  • Manifest exists: C:\Users\liuka\AppData\Local\OpenAI\extension\com.openai.codexextension.json
  • Bundled marketplace contains chrome and logs show chrome_native_host_install_requested

Relevant observations from logs

  • bundled_plugins_runtime_marketplace_written pluginNames=["browser","chrome","latex"]
  • chrome_native_host_install_requested ... nativeHostName=com.openai.codexextension
  • browser_use_availability_resolved available=true browserPane=true platform=Windows reason=available
  • There are browser_use_iab_backend_startup_ready entries
  • There are no corresponding extension/chrome backend startup ready entries

Workaround

  • In-app browser works
  • Chrome backend remains unavailable

Notes

This does not appear to be a simple extension install issue. The bridge files and registry are present, but the runtime still does not expose the extension backend.

View original on GitHub ↗

3 Comments

navi118 · 2 months ago

Thanks for the clear Windows repro. I maintain a small community Codex Skill focused specifically on Windows Codex Desktop failures around the bundled Chrome and Computer Use plugins:

https://github.com/navi118/codex-desktop-doctor-skill

It is not a general Codex repair script, and it does not make automatic destructive changes. The goal is to help an agent collect the relevant local evidence first, especially around the Codex Chrome Extension/native host, extension backend availability, bundled marketplace/cache state, and Windows file-lock / access-denied patterns such as plugin_cache_windows_file_lock, os error 5, missing-helper-path, or Windows Computer Use helper paths are unavailable.

For this issue, the Skill may be useful mainly to separate:

  • extension/native host registration being present,
  • the Chrome extension backend still not being exposed to the active runtime,
  • bundled plugin marketplace/cache inconsistencies,
  • and broader browser/runtime availability issues.

This may or may not be the same root cause as the cache/file-lock reports, but it can help gather comparable evidence for the Windows Chrome backend failure path.

dust2wood · 1 month ago

Additional reproducible evidence from a Korean Windows system:

Environment:

  • Windows 10 22H2 build 19045, x64
  • UI/system locale: ko-KR
  • Google Chrome 142.0.7444.60
  • Codex bundled Chrome plugin cache: 26.623.70822
  • Codex Chrome Extension: 1.1.5_0

Observed:

  • The extension is installed and enabled in both the Default and selected Profile 6 Chrome profiles.
  • The native host manifest exists and points to an existing extension-host.exe.
  • HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension exists, and its default value points to the correct manifest.
  • Nevertheless, agent.browsers.list() returns only iab, and agent.browsers.get("extension") fails with Browser is not available: extension.
  • Reinstalling the Chrome plugin multiple times did not help.
  • Opening a new Chrome window for the selected profile with the bundled open-chrome-window.js, waiting 2 seconds, and retrying also failed.

There is also a concrete locale bug in the bundled diagnostic:
scripts/check-native-host-manifest.js calls readRegistryValue(output, "(Default)"). On Korean Windows, reg query ... /ve labels the default value as (기본값), so the script reports the registry key as missing even though it exists and has the correct value.

This appears to be two related problems:

  1. The diagnostic is not locale-safe on non-English Windows.
  2. Even with a valid manifest, registry entry, extension, and host executable, the extension backend is not exposed to the Codex runtime.
zemeng5208 · 13 days ago

Disclosure: I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

The later Korean Windows reproduction here is useful because it separates two things: a locale-sensitive diagnostic can falsely say the default registry value is missing, while the actual extension/backend problem remains even when the manifest, registry, extension and host executable are all valid.

WinBridge approaches this by comparing the underlying state rather than relying on the English reg.exe label (Default). It also checks the active CODEX_HOME, bundled marketplace, versioned plugin cache/latest, native-host v2 references, and cua_node/node_repl generation together, because updates can leave those layers mutually inconsistent even when each individual file exists.

If those checks reveal local drift, WinBridge can back up and restore the affected user-writable layer from the official installed package. If the state is already coherent and the runtime still exposes only iab, it deliberately classifies that as an upstream backend/session-provisioning problem instead of forcing a fake Chrome backend.

If anyone reproducing this on Korean or another non-English Windows install tries it, please leave a short result at https://github.com/zemeng5208/winbridge-recovery/issues/4. Both successful and no-change reports are useful for separating local-state failures from the runtime routing bug.