Codex Desktop Chrome plugin: Native Messaging Host registry key missing on Windows

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

• #23283
• #22558
• #22598

Powered by Codex Action

Thanks for the duplicate check. I reviewed the suggested issues.

This looks related to #23283 and #22558, but my case has a slightly different diagnostic result:

• The native host manifest file exists:

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

• The Windows registry key is missing:

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

So this is not a full "manifest missing + registry missing" case. It appears that the installer created the manifest but did not register it with Chrome through the HKCU NativeMessagingHosts key.

If maintainers prefer tracking all Windows native-host registration failures under #23283, I am happy to close this as a duplicate. Otherwise, this issue may be useful as a narrower variant: manifest exists, registry registration missing.

Thanks for doing the leg work on this, I've been impacted as well and removing/reinstalling the extension and plugin doesn't fix.

@JCEY289 — your manifest-exists-but-registry-missing distinction is the load-bearing diagnostic and worth pinning. On Windows, Chrome doesn't scan filesystem manifest paths the way it does on macOS / Linux — it reads HKCU\Software\Google\Chrome\NativeMessagingHosts\<host> (or HKLM equivalent) at extension-init time, and the value of that key is the path to the manifest json. No registry key, no host discovery, regardless of how perfectly the manifest is laid out on disk. So the installer's split-step here ("write manifest" vs "write registry pointer") is exactly the seam #23283 + #22558 + your case all sit on, but yours is the cleanest narrow variant: manifest present, pointer absent.

The non-codex side of this is that the registry-key step requires either an HKCU write at install time (which some MDM-managed Windows environments quietly block) or a per-user re-register hook callable from the extension itself. Splitting manifest creation from registry pointer registration into separate idempotent steps that can be re-run without re-downloading the bundle usually shakes out a lot of these.

Chrome Relay (https://chrome-relay.kushalsm.com/) ships the same primitive (MV3 extension + native messaging host + CLI bridge) and intentionally writes the HKCU pointer as a separate chrome-relay install step that's idempotent and can be re-run if it failed silently. Useful as a bisect on the same Windows box: if chrome-relay install then chrome-relay tabs works, the OS-side plumbing is fine and Codex's installer logic is the diagnosable layer. @paulhshort — same applies on your machine.

Not a Codex replacement — different harness. Flagging because the install-step seam is reusable and the registry-key vs manifest distinction is worth documenting in the diagnostic flow.

— Kushal

We were able to get this working on Windows.

In our case, the native host manifest already existed at:

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

but Chrome could not discover it because the HKCU Native Messaging Host registry pointer was missing. Re-adding the default value fixed Chrome discovery:

reg add "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" /ve /t REG_SZ /d "%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json" /f

After that, reg query showed the key correctly, and the manifest pointed to the bundled extension-host.exe.

One extra note: the bundled checker script may still report the registry key as missing if its internal Node call to reg query fails with spawnSync reg EPERM. In our case that was a false negative from the checker environment, not proof that the registry key was still absent. A normal shell reg query succeeded, and Chrome later connected successfully.

Codex Chrome Plugin Native Host Report

Summary

Codex Chrome Extension is installed and enabled on Windows, but Codex cannot use Chrome-backed browser automation reliably because the Windows Native Messaging Host registry key is missing.

The failure observed in Codex browser automation is:

Browser Use virtual clipboard is not installed

This prevents Codex from filling forms or pasting text into authenticated Chrome sessions, even though the Chrome extension is enabled.

Environment

• OS: Windows
• Codex App version before update: 26.519.11010.0
• Codex App version after Microsoft Store update: 26.527.3686.0
• Chrome plugin bundle checked: 26.527.31326
• Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome Extension version: 1.1.5_0
• Chrome profile: Default
• Google Chrome path: C:\Program Files\Google\Chrome\Application\chrome.exe
• Google Chrome version reported by bundled check: 148.0.7778.181

What works

check-extension-installed.js --json reports the extension is installed and enabled:

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "selectedProfileDirectory": "Default",
  "installed": true,
  "enabled": true,
  "profiles": [
    {
      "profileDirectory": "Default",
      "installed": true,
      "registered": true,
      "enabled": true,
      "versions": ["1.1.5_0"],
      "selected": true
    }
  ]
}

What fails

check-native-host-manifest.js --json reports that the manifest file exists, but the Windows registry key is missing:

{
  "manifestPath": "C:\\Users\\u1201\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json",
  "registryKey": "HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension",
  "registryManifestPath": null,
  "expectedHostName": "com.openai.codexextension",
  "expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
  "exists": true,
  "correct": false,
  "problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension"
}

Steps already tried

• Confirmed Codex Chrome Extension is enabled in chrome://extensions
• Reinstalled/repaired the Chrome plugin from the Codex App multiple times
• Updated Codex App through Microsoft Store
• Restarted Codex App
• Restarted Chrome
• Restarted Windows
• Rechecked using the newer Chrome plugin bundle scripts

The missing registry key persists after all of the above.

Expected behavior

Reinstalling or repairing the Chrome plugin from Codex should create/register:

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

with the default value pointing to:

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

After that, Codex should be able to communicate with the Codex Chrome Extension and use Chrome-backed automation, including virtual clipboard / form filling.

Actual behavior

The Chrome extension remains installed and enabled, but native messaging is not registered. Browser automation can inspect some pages, but form filling and clipboard-backed operations fail with:

Browser Use virtual clipboard is not installed

Change .codex/config.toml.
Change windows.sandbox = "elevated" to windows.sandbox = "unelevated".
Then, Awesome!! I did it from Japan

Thanks for documenting the native messaging host registration failure. 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, bundled marketplace/cache state, Computer Use helper/native pipe availability, 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 relevant part is the Chrome native-host checklist: manifest path, registry key, extension ID/origin, whether the extension-host process is running, and whether the active Codex runtime actually exposes the Chrome extension backend after those local pieces are present.

Sharing it here as a diagnostic aid only; I would avoid treating manual registry/cache edits as safe general advice without first collecting the local evidence.

Still reproducible on Windows after reinstalling the Chrome plugin.

Environment:

• Codex Desktop: 26.707.3748.0
• Bundled Chrome plugin: 26.707.31428
• Google Chrome: 150.0.7871.114
• ChatGPT Chrome Extension: 1.2.27203.26575

Verified:

• The Chrome extension is installed and enabled.
• The native host manifest exists under %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json.
• HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension is still missing.
• Removing and reinstalling the Chrome plugin from the Codex plugin UI does not recreate the registry key.
• Codex navigation to https://example.com times out and remains at about:blank, while manual Chrome navigation works normally.

The plugin appears installed/enabled, but the Windows native-host registration step does not complete.

One Windows localization edge case can make the bundled native-host checker report a false missing-registry result.

On a French Windows installation, the registry key existed and was readable with:

reg.exe query HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension /ve

The localized output labels the unnamed value as (par défaut) rather than (Default).

The bundled check-native-host-manifest.js reported that the key/value was missing even though a direct reg.exe query returned the correct manifest path and Chrome could start the native host after the remaining path issues were repaired.

Suggested fix/test:

• parse the REG_SZ value independently of the localized unnamed-value label;
• or query the registry through a locale-independent API;
• add a test fixture for non-English reg.exe output, including French (par défaut).

This does not explain every Chrome connection failure, but it can send troubleshooting down the wrong path by classifying an existing registration as absent.