Windows: Chrome plugin install fails to create com.openai.codexextension Native Messaging Host

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

• #28880
• #28703

Powered by Codex Action

你解决这个问题了吗，我也遇到同样的问题

Reproduced on a newer Codex Desktop build. This appears to be the same failure mode as the original report.

Environment

• Windows 10 Home, version 10.0.19045, x64
• Codex Desktop package: OpenAI.Codex 26.715.2305.0
• Chrome: 150.0.7871.125
• Chrome plugin: chrome@openai-bundled 26.601.21317
• Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome extension version: 1.2.27221.15725_0
• Chrome profile: Default

Observed state

The Chrome extension diagnostic succeeds:

installed=true
enabled=true
registered=true
selectedProfileDirectory=Default

The plugin UI initially displays Failed to install plugin, but the Chrome plugin can later appear in the installed/enabled list. Despite that, the required Native Messaging Host remains completely absent:

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

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

check-native-host-manifest.js --json reports:

exists=false
correct=false
registryManifestPath=null
Windows native host registry key does not exist
Native host manifest does not exist

The ChatGPT Chrome side panel therefore continues to show:

Install the app to use ChatGPT in Chrome

Troubleshooting completed

• Updated Codex Desktop.
• Removed and re-added the Chrome plugin.
• Removed and reinstalled the Chrome extension.
• Closed and restarted all Chrome windows.
• Fully restarted Codex Desktop.
• Repeated the extension and native-host diagnostics after restart.
• Confirmed the extension is installed in the active Chrome profile.
• Confirmed the manifest was not mistakenly written to the Codex sandbox user profile or the Windows system profile.
• Confirmed the target %LOCALAPPDATA%\OpenAI\extension directory exists and the interactive Windows user has Full Control.

The plugin package copy appears to succeed, but the native-host setup step does not run or fails without rolling back the installed/enabled plugin state.

A desktop-app feedback report was also submitted with ID:

no-active-thread-019f71aa-ce8a-79d1-a822-1842469a56e2

This confirms the issue is still reproducible in Desktop 26.715.2305.0 with extension 1.2.27221.15725_0.

Confirmed on Codex Desktop 26.715.4045.0 with Chrome plugin 26.715.31925 and extension 1.2.27221.15725_0.

In my reproduction this was not a Chrome-extension problem. The WindowsApps runtime and bundled marketplace files were Archive, Encrypted / application-protected, and Electron/Node copying failed with Windows error 6000. The plugin then appeared installed/enabled, but native-host reconciliation never produced the manifest, HKCU key, v2 state, or latest junction.

A second important finding: a successful

codex plugin add chrome@openai-bundled

only installs the plugin payload. It does not by itself execute the desktop host service that creates/reconciles the Chrome native host, so CLI success is not proof that the browser integration is healthy.

The recovery was:

1. Close Chrome and plugin-owned host/diagnostic processes.
2. Copy the four official signed runtime executables into the exact cache directory expected by the current build with decrypted-destination semantics such as robocopy /COPY:DT.
3. Verify source/destination byte size, SHA-256, and Authenticode.
4. Mirror the bundled openai-bundled marketplace to a stable user-writable path using the same semantics and verify the complete tree.
5. Re-add the plugin through the supported flow, then let the desktop app perform its own native-host reconciliation.
6. Verify latest, .plugin-appserver, chrome-native-hosts-v2.json, the manifest, and the HKCU key before testing the real extension backend.

Do not manually fabricate the native manifest/registry and do not run installManifest.mjs.

After repair, I verified the real Chrome extension backend end-to-end by opening https://example.com/ and reading the title and DOM successfully.

Full root-cause and lifecycle detail is also posted in #32802.

Follow-up from the same Windows machine: the native host/side panel was recovered, but Chrome control still failed at the browser runtime bootstrap stage because Codex Desktop was pointing to a stale extracted CUA runtime.

Current environment

• Codex Desktop package: OpenAI.Codex 26.715.9868.0
• Codex CLI: 0.145.0-alpha.30
• Chrome plugin: chrome@openai-bundled 26.715.72028
• Chrome extension: 1.2.27221.15725

After the side panel connected successfully, a new Chrome-backed task ("open example.com in a new tab") failed with:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

The plugin's extension-host-config.json and the v2 native-host state both referenced:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_repl.exe

That cached runtime was stale:

runtime_archive_version: 0.0.1/20260609232601-73ffe8b8261e
node_repl_archive_path: 20260609.1/node_repl-20260609.1-x86_64-pc-windows-msvc.zip
node_repl.exe size: 13,513,728 bytes

The current Desktop package contains a newer runtime:

runtime_archive_version: 0.0.4/20260713191736-ad8b1874340f-pr-1124580
node_repl_archive_path: 20260713.2/node_repl-20260713.2-x86_64-pc-windows-msvc.zip
node_repl.exe size: 14,280,704 bytes

As a diagnostic workaround, I backed up the cached executable and replaced only node_repl.exe with the exact file from the current installed package. The destination SHA-256 was verified against the package source:

5419A4DBA576A319EB33D848131ACECA62AC189224211C84C0ECD932A8310CB8

After that replacement, the same browser task progressed past runtime bootstrap, performed the browser navigation policy check, and successfully opened https://example.com/ in a new Chrome tab.

A normal recursive copy from WindowsApps again failed with Windows error 6000 / "The specified file could not be encrypted"; a byte-for-byte destination write was required. The old executable remains backed up.

This suggests that a Codex Desktop update can leave the extracted cua_node runtime at 0.0.1 while the updated app/plugin continues referencing that stale cache directory. The app should invalidate or re-extract this runtime based on its manifest version/hash during update or Chrome-plugin reconciliation. This is related to the encrypted-package copy failure already described above and in #32802.

Desktop feedback report

A Codex Desktop feedback report with logs was submitted with ID:

019f71ba-3bc1-7de0-8c92-7d10a96bcbc2

Follow-up: Chrome control works in the Chrome side panel, but not from Codex Desktop tasks

This is an important correction to my previous successful test: opening https://example.com/ confirmed URL navigation only. It did not confirm element-level page interaction from a Codex Desktop task.

Environment

• Windows
• Codex Desktop: 26.715.9868.0
• Chrome plugin: 26.715.72028
• Chrome extension: 1.2.27221.15725

Reproduction

1. Created a fresh Codex Desktop task after the Chrome plugin and extension were installed and connected.
2. With a web application open in Chrome, explicitly invoked @Chrome and asked the Desktop task only to confirm that it could see the current tab, without making changes.
3. The fresh Desktop task failed with the equivalent of:

> Could not connect to the current Chrome tab, so I cannot confirm that I can see the page. No changes were made.

1. In the ChatGPT side panel inside the same Chrome tab, asked it to identify visible page content without editing.
2. The side panel correctly read the visible content.
3. As a safe interaction test, asked it to collapse and immediately expand an existing UI layer. It completed the action successfully, and the user directly observed both UI actions. No document content was modified.

Conclusion

The Chrome extension, native host, page reading, and element-level UI interaction are working from the Chrome side panel. The remaining failure is specifically the handoff/connection between a Codex Desktop task and the active Chrome tab.

Starting a fresh Desktop task does not clear the problem, so this is not only stale chat-specific state. The issue should not yet be considered fully resolved.

Related feedback ID: 019f71ba-3bc1-7de0-8c92-7d10a96bcbc2

Additional reproduction on a current Windows build (2026-07-26).

Environment:

• Codex Desktop Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64
• Codex CLI used by the active app session: 0.125.0
• Windows x64
• Google Chrome: 150.0.7871.182
• Official Chrome extension installed and enabled
• chrome@openai-bundled shown as installed/enabled in Codex

After fully restarting Codex and Chrome, then reinstalling both the Codex Chrome plugin and the Chrome extension, the UI still showed Chrome as connected, but agent-side Chrome discovery failed.

The installed state matched this issue exactly:

%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
{"schemaVersion":2,"entries":[]}

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

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

There were two additional broken installation artifacts:

1. %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest was missing, while only chrome\local existed. installManifest.mjs resolves a cache install to ..\latest, so the native-host install path could not complete normally.
2. The installed Chrome bundle also lacked its packaged docs directory, so after the runtime finally connected, browser.documentation() failed with Packaged browser documentation directory is missing.

The bundled browser-client.mjs then independently failed at bootstrap with:

Cannot redefine property: process

This is the same runtime incompatibility reported in #34372 (also related to #33001 / #32991). Reinstalling the plugin restored the same stale/incompatible artifact, so restart and reinstall did not help.

A local repair confirmed all layers:

1. Created a non-destructive chrome\latest junction pointing to chrome\local.
2. Kept the process shim module-local instead of assigning to the protected globalThis.process.
3. Restored the missing packaged browser API docs from the bundled Browser plugin.
4. Ran the official installManifest.mjs with the current Codex app runtime paths.
5. Verified check-native-host-manifest.js --json returned correct: true and the expected extension origin.
6. Re-ran backend discovery: it changed from extension: 0 to extension: 1.
7. Successfully listed the user's open Chrome tabs through the official extension backend.

This suggests the Windows Chrome plugin install/repair flow should be atomic and validate all of the following before reporting installed/connected:

• latest points to the active plugin payload;
• the native-host manifest exists;
• the HKCU NativeMessagingHosts registration points to that manifest;
• required packaged docs exist;
• the bundled client can initialize inside the current trusted runtime.

If any check fails, the installer should repair it or surface the exact failing step instead of leaving the plugin marked installed/enabled and the UI showing a misleading connected state.

Additional current-build reproduction (2026-07-27):

• Codex Desktop Microsoft Store package: 26.721.4979.0
• Chrome plugin: chrome@openai-bundled 26.721.41059
• Chrome extension: 1.2.27221.15725_0
• Chrome profile: Default

The plugin is installed/enabled and the official extension diagnostic reports the extension installed, registered, and enabled. However, the native-host installation is only partially present:

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

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

The official native-host manifest check exits with code 1, reports correct=false, and specifically identifies the missing registry key. After fully restarting Codex and Chrome, the Chrome side panel still says Install the app to use ChatGPT in Chrome / open the app if already installed, and browser-backend discovery exposes only the in-app browser (iab), not the Chrome extension backend.

No manifest or registry entry was manually created or edited for this verification.

This is a slightly different partial-install state from the original both-missing case: the manifest file exists, but registration did not complete. The installer/repair flow should validate the manifest, the HKCU registration, and real extension-backend discovery before reporting the plugin as installed/enabled or connected; otherwise it should repair the missing step or surface it explicitly.

Follow-up: packaged desktop detector ignores isolated Chrome profiles, and native-host reconciliation does not enforce the registry postcondition

Additional read-only diagnosis on the current Windows ARM64 build (2026-07-27), extending the current-build reproduction already reported above.

Environment

• Codex Desktop Microsoft Store package: 26.721.4979.0
• Chrome plugin: chrome@openai-bundled 26.721.41059
• Chrome extension: 1.2.27221.15725_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome uses an isolated profile root under %USERPROFILE%\.codex\chrome-profiles\<scope>

Confirmed profile-detection mismatch

Running the bundled extension diagnostic without overrides selects:

%LOCALAPPDATA%\Google\Chrome\User Data\Default
installed=false
enabled=false
exitCode=2

Running the same diagnostic with CODEX_CHROME_USER_DATA_DIR and CODEX_CHROME_PREFERENCES_PATH set to the isolated profile reports:

selectedProfileDirectory=Default
installed=true
enabled=true
exitCode=0
extensionVersion=1.2.27221.15725_0

Packaged-code inspection explains the mismatch:

• The desktop sync detector scans only %LOCALAPPDATA%\Google\Chrome\User Data\<profile>\Extensions\<extensionId>.
• Its caller supplies only the extension ID; it does not use CODEX_CHROME_USER_DATA_DIR or CODEX_CHROME_PREFERENCES_PATH.
• The bundled plugin's own check-extension-installed.js and open-chrome-window.js do honor those overrides.

This creates two different answers inside the same shipped product: the plugin diagnostic sees the active isolated profile, while Desktop reconciliation concludes that the extension is absent.

Lifecycle evidence

Startup logs show the consequence:

1. When the plugin was sync-managed, Desktop logged isExtensionInstalled=false, selected uninstall_managed, uninstalled the plugin, and removed native-host state.
2. After the plugin was reinstalled through the UI, the managed marker was absent. Desktop logged keep_user_managed with isExtensionInstalled=false.
3. With the plugin current, native-host reconciliation completed without a visible error, but the required state remained:

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

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

The official native-host checker exits 1 and reports correct=false. Extension-backed discovery remains unavailable.

The packaged Windows registration path invokes reg add for the HKCU key, but does not query the value afterward and compare it with the expected manifest path. Therefore reconciliation can finish without enforcing the required postcondition.

Suggested durable fix

1. Use the bundled profile-aware detector in Desktop reconciliation, or pass the configured/active Chrome profile roots through the desktop detector.
2. Treat the extension as present if it exists in any configured isolated root; do not infer global removal from only the normal Default profile.
3. After native-host registration, query the HKCU value and compare it with the expected manifest path. Fail reconciliation visibly if it is absent or wrong.
4. Add Windows regression coverage for:

• extension installed only in a custom profile root;
• current user-managed plugin repairing a missing registry key;
• managed cleanup removing only cache-owned native-host state.

No registry entries, manifests, app-package files, or plugin-cache files were manually changed during this diagnosis.

Related Codex task ID: 019fa2b2-be95-71e3-ba4e-aa9d80af56a3

Update withdrawn. The local Chrome integration issue has been resolved after moving the Microsoft Store Codex/ChatGPT app package from a secondary AppX volume to the Windows system drive and reinstalling the bundled Chrome plugin. The original issue was created by another user; this comment was only an additional reproduction report.

Disclosure: I’m the author/maintainer of WinBridge Recovery, an independent Windows recovery utility for Codex Desktop.

The inconsistent state described here — Chrome plugin installed/enabled, extension present, but the Native Messaging manifest/registry entry and chrome-native-hosts-v2.json not materialized correctly — overlaps directly with the native-host registration checks in the project.

The tool discovers the currently installed official Codex package and user-side plugin cache, backs up the existing configuration/registration state, validates the expected host executable and paths, and repairs local registration/pointer drift when it can derive the correct values from the installed official files. It does not fabricate a third-party host binary and does not modify WindowsApps.

This still shouldn’t be treated as an upstream installer fix: if the current Codex build itself refuses to provision the host for a product/entitlement reason, the tool cannot change that. But for a partial-install state where the official plugin files exist and only the user-side native-host registration is missing/stale, this is one of the scenarios WinBridge Recovery is intended to recover.

I can reproduce this issue on Windows.

Feedback ID: 01a01793-5f01-7702-b077-043a4ca445c2

Environment

• Codex Chrome plugin version: 26.814.41407
• Codex Chrome extension version: 1.2.27259.19709_0
• Chrome profile: Default
• The official Codex Chrome extension is installed and enabled.

Observed behavior

The extension is detected as installed and enabled, but the following Native Messaging Host components are both missing:

• Registry key:

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

• Manifest:

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

Chrome control also fails during initialization with the following error:

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

I reinstalled the Codex Chrome plugin three times and also tested it in newly created Codex chats, but the same failure persists.
This appears to involve both the missing Native Messaging Host registration described in this issue and a trusted plugin-path/runtime initialization problem similar to #21781 and #23414.