›_ Codex Issues
Codex Issues / #22558

Codex Chrome plugin says connected in app but Chrome extension stays Disconnected on Windows

Open 💬 4 comments Opened May 13, 2026 by rodrigosardinha

What version of the Codex App are you using (From “About Codex” dialog)?

v1.1.4

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows x64 + WSL Chrome on Windows Codex desktop app Chrome extension v1.1.4

What issue are you seeing?

The Codex Chrome plugin appears connected/installed in the Codex app, but the Chrome extension popup always shows:

Disconnected
Use the Chrome plugin in Codex to connect.
Version v1.1.4

Codex opens Chrome and asks me to install the extension. The extension is installed, but it never connects. Reinstalling/reconnecting the Chrome plugin from Codex does not fix it.

Diagnostics:

  • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome extension version: v1.1.4
  • Plugin package seen locally: chrome@openai-bundled 0.1.7
  • The native host is not registered on Windows.

Missing manifest:
C:\Users\rodri\AppData\Local\OpenAI\extension\com.openai.codexextension.json

Missing registry key:
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Official checker output:
Windows native host registry key does not exist; Native host manifest does not exist.

There is no visible error in the Codex app. It just keeps opening Chrome/install flow, while the Chrome extension remains Disconnected.

Expected:
Connecting/reconnecting the Chrome plugin from Codex should create the native host manifest and Windows registry key, then the Chrome extension should show connected.

Actual:
The Chrome extension stays Disconnected forever.

What steps can reproduce the bug?

  1. On Windows, install/connect the Chrome plugin from the Codex desktop app.
  2. Codex opens Chrome and prompts to install the Codex Chrome Extension.
  3. Install the extension.
  4. Click the Codex Chrome Extension icon in Chrome.

Result:
The extension popup shows:

Disconnected
Use the Chrome plugin in Codex to connect.
Version v1.1.4

  1. Disconnect/reconnect or reinstall the Chrome plugin from the Codex app.
  2. Repeat the Chrome extension install/connect flow.

Result remains the same: the Chrome extension stays Disconnected.

Diagnostics run locally:

  • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome extension version: v1.1.4
  • Plugin package: chrome@openai-bundled 0.1.7
  • Native host manifest is missing:

C:\Users\rodri\AppData\Local\OpenAI\extension\com.openai.codexextension.json

  • Windows registry key is missing:

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

Official checker output:
Windows native host registry key does not exist; Native host manifest does not exist.

What is the expected behavior?

After connecting the Chrome plugin from the Codex desktop app, Codex should create/register the native messaging host on Windows.

Expected files/registry:

  • C:\Users\rodri\AppData\Local\OpenAI\extension\com.openai.codexextension.json
  • HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Then the Chrome extension should connect successfully and no longer show "Disconnected".

Additional information

There is no visible error in the Codex app. The app keeps opening Chrome / extension install flow, but the extension remains disconnected.

Reinstalling the Chrome extension and reconnecting the plugin from Codex did not fix it.

This is blocking use of the Chrome plugin in Codex on Windows.

View original on GitHub ↗

4 Comments

MisterRound · 3 months ago

Give my issue to your codex, I got it working after a ton of hair pulling

https://github.com/openai/codex/issues/21971

rodrigosardinha · 3 months ago
Give my issue to your codex, I got it working after a ton of hair pulling #21971

Thanks. I saw #21971. My case seems related but fails earlier.

In #21971 the native host manifest/registry already exists and the failure is during Node REPL / browser-client bootstrap.

In my case, after deleting the plugin cache, the Chrome plugin install itself fails with:

ENOENT: no such file or directory, open 'C:\mnt\c\Users\rodri\.codex\.tmp\bundled-marketplaces\openai-bundled\.agents\plugins\marketplace.json'

So Codex is still converting /mnt/c/... into C:\mnt\c\... before the plugin/native host setup completes.

If you have a workaround for this earlier install phase, please share the exact steps.

CRKJAO · 2 months ago

I can reproduce this on Windows with a newer Codex Desktop build after a clean reinstall.

Environment:

  • Codex Desktop: 26.623.4041.0
  • Bundled Chrome plugin: 26.623.31921
  • Google Chrome: 149.0.7827.201
  • Codex Chrome Extension: 1.1.5_0
  • Selected Chrome profile: Default

Verified working:

  • Chrome is installed and running.
  • The bundled Chrome plugin package is complete (.codex-plugin/plugin.json and scripts/browser-client.mjs exist).
  • The Chrome extension is installed, registered, and enabled.

Still missing after remediation:

  • %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
  • HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

The bundled checker reports both the native-host manifest and registry key as missing.

Remediation already attempted:

  1. Removed a partial plugin cache left by a failed uninstall/install.
  2. Reinstalled chrome@openai-bundled from a clean state through the Codex plugin flow.
  3. Confirmed the plugin package and Chrome extension checks pass.
  4. Fully restarted Codex Desktop.
  5. Re-ran the native-host checker; both the manifest and registry entry remain absent.

This suggests the Windows native-host installation hook is still not running (or is failing without a visible error) in Codex Desktop 26.623.4041.0.

zemeng5208 · 16 days ago

Disclosure: I maintain WinBridge Recovery, an independent Windows recovery/diagnostic utility for Codex Desktop.

There seem to be two local-state layers mixed in this report: the missing Native Messaging Host, and the earlier marketplace path contamination where a WSL-style /mnt/c/... value becomes an invalid Windows path like C:\mnt\c\... before plugin installation completes.

The missing-host portion is within WinBridge Recovery’s intended scope when the official Chrome plugin payload exists: it validates the current plugin cache/latest, host executable, manifest/HKCU registration and related Desktop host state against the currently installed official package, with backup before repair.

The /mnt/c -> C:\mnt\c conversion is more interesting as a diagnostic case. I would not blindly rewrite arbitrary user paths, but it is a good candidate for a preflight check: detect a marketplace/CODEX_HOME path whose syntax belongs to WSL but is being consumed by the Windows Desktop runtime, flag it explicitly, and avoid destructive plugin repair until the ownership/path layer is consistent.

So I would treat WinBridge as a recovery aid here, not a guarantee that it can fix the underlying WSL/Desktop path-normalization bug.