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.

Additional same-machine comparison evidence:

On the same Windows computer, using the same Google Chrome installation, the same Chrome profile, the same logged-in government-service page, and the same network, Claude Code can successfully control Chrome end to end.

Verified behavior in Claude Code:

• attached to the existing authenticated Chrome session;
• read the current page and discovered the real attachment download links;
• clicked and downloaded all 15 image attachments;
• verified the files in Chrome's configured download directory (D:\Downloads);
• moved the downloaded files into a desktop folder.

In contrast, Codex Desktop in this environment still does not expose/initialize a usable Chrome browser-control entry point, even though the Codex/ChatGPT Chrome extension has been installed and enabled and the repair/reinstall flow has already been attempted.

This comparison makes a general Windows Firewall, Chrome permission, website restriction, download-directory permission, or network failure much less likely. It points more specifically to the Codex Desktop ↔ Chrome extension/native-host initialization or runtime tool-exposure layer.

For privacy, I am not attaching the authenticated page contents, account details, or downloaded complaint images. I can provide redacted screenshots of the successful Claude control flow if maintainers need them.

I maintain WinBridge Recovery, an independent Windows recovery launcher for Codex Desktop bundled Browser/Chrome/Computer Use state. This issue is a particularly clean example of why I now treat Native Host state as multiple independent layers rather than a single “installed/not installed” flag.

For this exact variant — manifest exists, but HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension is missing — WinBridge v3.1.1 already validates the manifest, Chrome/Edge HKCU registration, chrome-native-hosts-v2.json, host executable path, plugin cache/version, latest, CLI/Node paths, and related runtime paths separately. That lets it distinguish “manifest missing” from “registry pointer missing” instead of treating both as one generic Chrome failure.

The current project can reconstruct/roll back the user-side Native Host state when it is inconsistent, but I am also tracking a safer long-term design: restore/verify the official runtime + marketplace + plugin cache first, let Codex Desktop perform its own Native Host reconciliation when possible, and use direct manifest/registry reconstruction only as a controlled fallback. I do not want the recovery tool to become permanently coupled to an internal schema if the official app can regenerate it correctly.

One detail from the discussion here is especially useful for diagnostics: a checker failure such as spawnSync reg EPERM should not automatically be interpreted as proof that the HKCU key is absent. A recovery/doctor path should distinguish “registry query itself failed” from “query succeeded and key is missing.” I’m adding that distinction to the project roadmap as well.

WinBridge only works from the official package already installed on the machine; it does not modify WindowsApps ownership/ACLs or bypass browser/enterprise security policy.

#24040:

:::writing{variant="standard" id="41827"} I can confirm that this issue is still reproducible on a much newer Codex for Windows build.

Environment:

Windows

Codex runtime/plugin version: 26.814.41407

Codex Windows package: OpenAI.Codex_26.814.5167.0_x64

Chrome extension version: 1.2.27259.19709_0

Chrome profile selected by the diagnostic tool: Profile 1

Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Current state:

The Chrome extension is installed and enabled.

The native-host manifest exists at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json.

The manifest points to an existing extension-host.exe.

chrome-native-hosts-v2.json contains a current entry for version 26.814.41407.

The required registry key is still missing:

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

The bundled diagnostic reports:

Windows native host registry key does not exist: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Reinstalling and re-enabling the Chrome plugin and extension did not repair the registration.

There also appears to be a related runtime-routing problem. Initializing the Chrome browser client fails with:

Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

This error occurs even when the browser client is loaded directly from the current chrome/26.814.41407 plugin directory, after resetting the Node session.

This suggests that the current Windows build still has two related problems:

1. The Chrome plugin installation lifecycle does not create or repair the required Native Messaging Host registry key.

1. The Chrome browser client may be routed to the browser plugin service path instead of the trusted chrome plugin service path.

Please provide an officially supported repair procedure or fix the installer/runtime so it recreates the registry entry and selects the correct trusted browser-service path. :::

I managed to make it work here. Same class of false negative as this issue, on Portuguese Windows. Direct reg.exe query succeeds; the bundled checker still reports the key missing. Two independent parser/spawn bugs stack:

1. check-native-host-manifest.js looks for the English label (Default). Portuguese reg query /ve prints (padrão) (same as the already-reported French (par défaut)).
2. When the Codex sandbox cannot spawn reg.exe (spawnSync reg EPERM), the catch path returns null and the checker sets registryKeyExists: false. Spawn failure is treated as “key absent.”

In this environment the HKCU pointer and manifest were already correct:

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

Chrome page reading still worked (native messaging + extension were fine). Interactive click/type tools were not attached to the task until the checker stopped failing. After that, a new task could control Chrome.

Suggested checker semantics:

• If reg query cannot be spawned (EPERM / EACCES / ENOENT), treat the registry as unknown (registryKeyExists: null), not missing.
• If /ve output contains a parenthesized localized default label, parse the REG_SZ path anyway.
• Only emit “registry key does not exist” when the query actually ran and the value was absent.

Workaround that does not require editing the registry: the checker already honors

CODEX_CHROME_NATIVE_HOST_MANIFEST_PATH
CODEX_CHROMIUM_NATIVE_HOST_MANIFEST_PATH

pointing at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json. That skips the reg.exe call. User-level env vars survive plugin updates better than patching the cached script.

Repair / Reset / reinstall of Codex and reinstall of the Chrome extension did not recreate a “missing” key here, because the key was not missing.

Versions:

• Windows, display language Portuguese
• Codex Desktop 26.814.5517.0 / plugin 26.814.41957
• Chrome extension 1.2.27267.15375

---

If you are stuck on Windows and only want a local workaround

1. Confirm the key exists (do not skip this):

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

If that fails, create it:

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

1. Set User environment variables (not System):

$manifest = "$env:LOCALAPPDATA\OpenAI\extension\com.openai.codexextension.json"
[System.Environment]::SetEnvironmentVariable('CODEX_CHROME_NATIVE_HOST_MANIFEST_PATH', $manifest, 'User')
[System.Environment]::SetEnvironmentVariable('CODEX_CHROMIUM_NATIVE_HOST_MANIFEST_PATH', $manifest, 'User')

1. Fully quit Codex (including the tray icon) and Chrome, then reopen both.
2. Start a new Codex task and try a click, not the old conversation.

Those env vars make the bundled checker skip reg.exe. They survive plugin updates better than editing the cached script.

I’m experiencing this same issue on Windows with OpenAI.Codex 26.820.7780.0.

The Chrome sidebar can read the current tab, but it cannot open tabs, click, type, scroll, or navigate. It reports that the Codex Chrome native host is out of date.

The bundled diagnostic confirms:

• The native-host manifest exists at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
• The required registry key is missing:

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

• registryManifestPath is null
• correct is false

Attempted without success:

• Fresh Codex sidebar chat
• Removed and reinstalled the official Chrome extension through Settings → Computer use
• Restarted the ChatGPT/Codex desktop app
• Fully restarted Chrome

In-app feedback was uploaded with Feedback ID:
01a03e79-c0c9-7b60-bf74-62f50717c92c

No manual registry modification was attempted.