›_ Codex Issues
Codex Issues / #21674

Windows: Chrome plugin shows "Install failed" in Codex UI even though Chrome extension is installed and enabled

Open 💬 4 comments Opened May 8, 2026 by TTTTTIGER
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, the Chrome plugin in Codex UI cannot be installed successfully.

The plugin card shows that Chrome needs installation, but clicking install fails in the UI.
This happens even though:

  • Google Chrome is installed
  • the Codex Chrome extension is already installed in Chrome
  • the Codex Chrome extension is enabled
  • the local native host manifest file can exist correctly

At the same time, other plugins such as Gmail can be installed successfully from the same Codex UI on the same machine.

This suggests the problem is specific to the local install/bridge flow for the Chrome plugin, not a general plugin-install failure.

Environment

  • OS: Windows
  • Codex Desktop
  • Local Codex version metadata indicates 0.128.0 as the latest checked version

What I observed

1. Codex UI behavior

  • In Codex UI, Chrome plugin state was inconsistent across attempts
  • After cleanup, the UI correctly showed that Chrome needed installation
  • Clicking install in the Codex UI failed
  • After the failed install, the local install state was not fully restored by the UI flow
  • By contrast, Gmail plugin installation from the same Codex UI worked

2. Chrome-side state is present

Chrome is installed.

The Codex Chrome extension is installed and enabled in the Chrome Default profile.

A local plugin check script reports the extension as installed and enabled.

3. Native host bridge is where things break

The local manifest file can exist at:

  • %LOCALAPPDATA%\\OpenAI\\extension\\com.openai.codexextension.json

Expected registry key:

  • HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension

The plugin check script still reports that the native host registry key is missing / not visible to the runtime, even when the manifest file exists.

Representative result:

{
  "manifestPath": "%LOCALAPPDATA%\\OpenAI\\extension\\com.openai.codexextension.json",
  "registryKey": "HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension",
  "exists": true,
  "correct": false,
  "problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension"
}

4. Runtime symptom

When trying to actually use @chrome, the plugin did not become usable in-session.

A lightweight connection/bootstrap test timed out instead of returning open tabs.

Reproduction steps

  1. Open Codex Desktop on Windows.
  2. Go to the plugin UI.
  3. Find the Chrome plugin.
  4. Click install.
  5. Observe that installation fails in the UI.
  6. Try using @chrome in a new conversation.
  7. Observe that the plugin is still not usable.

Expected behavior

Clicking install for the Chrome plugin should:

  • enable the plugin in Codex config
  • create/update the native host manifest
  • create/update the required Windows registry entry
  • make @chrome usable in a fresh conversation

Actual behavior

  • Codex UI reports install failure for Chrome
  • @chrome remains unusable
  • Chrome extension itself is already installed and enabled
  • The failure appears to be in the native host / local bridge install flow

Additional notes

  • This is not a general plugin installation failure: Gmail can be installed successfully from the same UI
  • Restarting the machine did not resolve it
  • The issue appears specific to the Chrome plugin’s local Windows install/bridge path
  • Local Codex logs also showed plugin/app directory sync failures, including 403 Forbidden responses for plugin/app directory requests, which may be related to unstable plugin state in desktop

Possible area to investigate

  • Windows-specific native host registration during Chrome plugin install
  • Whether the desktop app is writing the registry entry successfully
  • Whether the runtime/plugin checker is reading the same registry hive/context as the installer
  • Whether plugin install state in UI can diverge from actual local bridge state

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21670

Powered by Codex Action

rodrigoantonioli · 3 months ago

I can reproduce a related Windows/localization edge case.

On my machine, the registry key does exist:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

and reg query ... /ve returns:

(padrão) REG_SZ C:\Users\rodri\AppData\Local\OpenAI\extension\com.openai.codexextension.json

However, check-native-host-manifest.js --json still reports:

"registryManifestPath": null
"problem": "Windows native host registry key does not exist..."

Looking at the script, it parses the reg.exe output looking specifically for (Default). On a Portuguese Windows install, the default value label is localized as (padrão), so the check appears to produce a false negative even though Chrome can later connect successfully.

After opening Chrome and using the trusted bundled marketplace path for browser-client.mjs, the Chrome extension backend was detected and I could open https://example.com/ and read the title.

wi11zy957 · 1 month ago

Also reproducible on a current Windows installation after completing the official troubleshooting flow.

Environment:

  • Windows 11 Pro 25H2, build 26100.8655, x64
  • ChatGPT/Codex Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Codex Desktop client/plugin version reported locally: 26.721.41059
  • Google Chrome: 150.0.7871.187
  • Chrome plugin: chrome@openai-bundled, version 26.721.41059

Verified state:

  • Chrome is installed and is the effective handler for HTTP, HTTPS, HTML, HTM, and PDF.
  • The Chrome plugin payload is present in the local Codex plugin cache and its extension-host.exe exists.
  • %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json is missing.
  • HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension is missing.
  • Other native messaging hosts are visible normally under the same Chrome registry locations.

Troubleshooting completed:

  1. Updated/verified ChatGPT/Codex as the latest Microsoft Store version.
  2. Repaired the ChatGPT package successfully with Windows Package Manager.
  3. Restarted the desktop app.
  4. Removed and re-added the Chrome plugin from Plugins.
  5. Retried installation after repair.

Result: the Chrome plugin still immediately reports Install failed, and neither the native host manifest nor the registry pointer is created. The local Codex logs show plugin list refreshes but no actionable installer error. This still appears to be a Windows desktop post-install/native-host registration failure rather than a Chrome profile or extension problem.

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop local plugin/bridge recovery: https://github.com/zemeng5208/winbridge-recovery

The newer 26.721 reproduction here is a direct match for the Native Host consistency layer WinBridge checks: the Chrome plugin payload and extension-host.exe are present, but %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json and the HKCU NativeMessagingHosts pointer are both missing after the official install/repair flow.

WinBridge validates the Chrome plugin cache/latest, Native Messaging manifest, Chrome/Edge HKCU registrations, and chrome-native-hosts-v2.json as separate state. Its current v3.1.1 recovery path can back up those user-owned entries and reconcile an inconsistent local bridge instead of treating “plugin installed” as proof that Native Host setup completed.

One caveat from this same thread is important: a checker failure is not always proof the key is absent — localized reg.exe output can cause false negatives. A recovery tool should distinguish “query failed/indeterminate” from “query succeeded and key is actually missing” before writing anything.

Longer-term I am moving the project toward preferring the official Desktop native-host reconcile lifecycle first and using manual reconstruction only as a controlled fallback. It does not bypass Chrome/enterprise policy, account gates, or patch the installed AppX package.