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

Open 💬 2 comments Opened May 8, 2026 by TTTTTIGER

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 ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗