Windows Codex Chrome plugin installed/enabled but native host manifest and registry key are never created

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

• #31904

Powered by Codex Action

I can reproduce this on a second Windows machine with the same desktop package, and I was able to identify the failure before native-host registration.

Environment

• Windows 11 23H2, x64
• ChatGPT/Codex desktop package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
• Bundled Chrome plugin: 26.707.62119
• Chrome extension installed and enabled in the selected profile

Root cause

The plugin payload/config step succeeds, but the desktop app fails while relocating its bundled Electron runtime from WindowsApps:

plugin_install_succeeded pluginName=chrome
bundled_executable_relocation_failed
  operation=copy_file
  errorCode=UNKNOWN
  originalError={"errno":-4094,"code":"UNKNOWN","syscall":"copyfile",...}
manual_plugin_install_failed
  Missing bundled Electron runtime required to sync Chrome native host resources
  for com.openai.codexextension: codex

The affected source files are:

resources\codex.exe
resources\codex-code-mode-host.exe
resources\codex-windows-sandbox-setup.exe
resources\codex-command-runner.exe

All four are valid OpenAI-signed files, but Windows reports them as Compatibility Level: Application Protected / Archive, Encrypted. The current relocation path uses Node/Electron copyFileSync, which fails when copying these protected WindowsApps files to a normal user directory.

For this build the app computes the runtime cache directory:

%LOCALAPPDATA%\OpenAI\Codex\bin\3135b80b111fd431

The app validates the four cached files by type, size, and SHA-256. Because relocation fails before that directory is created, native-host reconciliation never reaches the steps that create:

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
%USERPROFILE%\.codex\chrome-native-hosts-v2.json
%USERPROFILE%\.codex\plugins\.plugin-appserver

This explains why the UI/CLI reports the plugin installed and enabled while Chrome still reports the app/native host as missing.

Verified recovery

As a local diagnostic workaround, I copied the four official files with data/timestamp only semantics (equivalent to robocopy /COPY:DT) into the expected hash directory, then verified each destination file against the WindowsApps source by size, SHA-256, and Authenticode signature.

After the app regained focus and the Chrome plugin install flow was retried, the app completed its own supported reconciliation and created the native-host manifest, registry entry, v2 host state, and .plugin-appserver. Chrome then connected successfully. I did not run installManifest.mjs or manually create the manifest/registry entry.

The bundled marketplace materialization in this package shows the same protected-file failure pattern when Electron tries to copy files from resources\plugins.

Suggested fix

The later .plugin-appserver materialization path already appears to have a decrypted-destination fallback. The earlier WindowsApps runtime relocation path should use the same behavior (or the Windows equivalent of COPY_FILE_ALLOW_DECRYPTED_DESTINATION) instead of plain copyFileSync.

It would also help if the install UI surfaced the underlying relocation error rather than only reporting that Chrome/the extension is not installed.

Follow-up: I have now validated a durable local self-heal workaround for this failure class. This is not a replacement for fixing the WindowsApps copy path in the app, but it prevents the same Store update from leaving the browser integration broken on this machine.

Self-heal design

• Runs as the current user with an interactive token and least privilege.
• Event trigger: Microsoft-Windows-AppXDeploymentServer/Operational, provider Microsoft-Windows-AppXDeployment-Server, event ID 400, filtered to DeploymentOperation=6 and PackageDisplayName=ChatGPT, with a 45-second delay.
• Delayed logon fallback: 5 minutes.
• Maximum runtime: 10 minutes; hidden; does not wake the machine; overlapping runs are ignored.
• A package change or failed quick check runs full repair/verification. An unchanged healthy package takes a lightweight path; a full integrity check is forced periodically.
• Uses a mutex, verified staging directories, same-volume atomic renames, rollback/quarantine, bounded retention, and SHA-256/tree verification.
• Mirrors the bundled marketplace to a stable local path so Store version-directory changes do not leave the registration pointing at stale content.
• Does not change WindowsApps ACL/EFS attributes, kill Chrome/Codex, run installManifest.mjs, or manually write the Native Messaging manifest/registry. Native-host reconciliation remains owned by the desktop app.

Verified state

Package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0

Verified hashes/fingerprints:

• Runtime aggregate: 3135b80b111fd43124fd448d7c84cbb228f7301d66322c36577229724eaf2f24
• CUA anchor aggregate: ecfc0d9aa02807e36598fc7c4f64f0a1060172dc94ccbc574600af802a415d61
• Bundled marketplace tree: e6611a5836848a97c27c7bb4ed8a4c99ded91809dba9ff0312cc8b1eaea73204

The final full audit passed the four-file runtime cache, full 3,558-file CUA Node tree, stable marketplace mirror/registration, Native Messaging manifest and Chrome HKCU registration, both v2 host-state files, .plugin-appserver, required plugins, and the scheduled-task definition.

I manually started the task. It returned to Ready in about 2 seconds with LastTaskResult=0 and logged scheduled_fast_path_healthy. All 29 pre-existing Chrome/Codex/ChatGPT processes were still running afterward, and a fresh Chrome-extension control connection successfully enumerated the open tabs.

The product-side fix remains the same: the early WindowsApps runtime/marketplace relocation path needs a decrypted-destination-capable copy fallback instead of plain Electron/Node copyFileSync.

I can reproduce this on another Windows machine, including after a fully automated transactional uninstall/reinstall. This remains broken in a newer Store package, and in this case the four-file runtime relocation workaround described above is already satisfied.

Environment

• Windows x64
• ChatGPT/Codex Desktop package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Codex CLI: 0.144.2
• Bundled Chrome plugin cache: 26.623.31921
• Chrome extension: 1.2.27203.26575_0
• Selected Chrome profile: Profile 1
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Affected task ID (logs submitted through ChatGPT/Codex): 019f61c7-af98-7851-886c-b9b646007174

Symptoms and official diagnostics

The desktop settings page shows a green Connected badge, but the Chrome extension says “Install the app to use ChatGPT in Chrome.”

check-extension-installed.js --json succeeds:

{
  "selectedProfileDirectory": "Profile 1",
  "installed": true,
  "registered": true,
  "enabled": true,
  "versions": ["1.2.27203.26575_0"]
}

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

{
  "registryManifestPath": null,
  "exists": false,
  "correct": false,
  "problem": "Windows native host registry key does not exist; Native host manifest does not exist"
}

Both remain absent:

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

The Chrome backend reports:

Browser is not available: extension

Recovery attempts completed

1. Reinstalled the Chrome extension through the desktop UI.
2. Removed and reinstalled chrome@openai-bundled through both UI and CLI.
3. Completely closed Chrome and extension-host.exe, then restarted Codex first.
4. Repaired the Store package with winget repair.
5. Performed a complete Store uninstall/reinstall of product 9PLM9XGG6VKS.
6. Before uninstalling, made and hash-verified a complete backup of %USERPROFILE%\.codex.
7. Verified complete package removal, then installed a fresh 26.707.9981.0.
8. Quarantined the old Chrome plugin cache and confirmed the reinstalled app rebuilt it from scratch.
9. Preserved and re-verified config, auth, MCP configuration, and session history.
10. Relaunched Codex with Chrome closed and waited two minutes for native-host reconciliation.
11. Re-ran the bundled official diagnostics after the clean reinstall.

The manifest and registry key were still not created.

Additional evidence relative to the runtime-copy workaround

The expected runtime cache already exists at:

%LOCALAPPDATA%\OpenAI\Codex\bin\3135b80b111fd431

All four cached executables:

• exist at both the WindowsApps source and cache destination;
• have identical byte lengths;
• match the source SHA-256 exactly; and
• have valid Authenticode signatures.

Files verified:

codex.exe
codex-code-mode-host.exe
codex-windows-sandbox-setup.exe
codex-command-runner.exe

%USERPROFILE%\.codex\plugins\.plugin-appserver exists, but %USERPROFILE%\.codex\chrome-native-hosts-v2.json does not. I also found no bundled_executable_relocation_failed or Missing bundled Electron runtime lines in the available desktop logs.

So this machine reaches a different failure state: the verified runtime cache and plugin appserver are present, yet Chrome native-host reconciliation still never creates the v2 state, manifest, or registry entry.

Impact

This is a subscription-blocking issue for me. Authenticated control of my existing Chrome session is the primary reason I considered replacing another coding-agent subscription with Codex; without working Chrome integration on Windows, that workflow is disqualified.

Please make the UI validate the actual native-host state before displaying Connected, surface the underlying reconciliation error, and repair the native host automatically when the plugin is installed or rebuilt.

Quick update: I finally got this working.

Reinstalling the app and extension was not the answer. On my Windows machine, two WMI process classes that Codex relies on were missing. That caused the bundled Chrome plugin setup to fail before Codex could create the native messaging host.

This explains the confusing behavior. Codex said Chrome was "Connected," while the extension still said "Install the app."

I do not have admin rights, so instead of repairing WMI, I used a small user-scoped PowerShell compatibility shim for those process queries. I also removed a stale marketplace entry left over from earlier troubleshooting and restarted Codex. After that, Codex successfully created its own manifest, registry entry, plugin cache, and native host.

I verified it end to end through the real Chrome extension backend. Codex detected my open tabs, searched YouTube, and opened a video.

The underlying issue appears to be that Chrome setup completely fails when those Windows WMI queries are unavailable. It would be helpful if Codex could fall back to another process-listing method and if "Connected" reflected an actual native-host connection.

I am happy to share the workaround scripts and logs if they would help.

Confirmed on a newer Windows Store build, with an additional detail that explains why a successful CLI reinstall can still leave the Chrome backend unavailable.

Environment

• Codex Desktop AppX: OpenAI.Codex 26.715.4045.0
• Bundled Chrome plugin: 26.715.31925
• Chrome extension: 1.2.27221.15725_0
• Windows x64, Chrome Default profile

Root cause observed

The AppX files under WindowsApps were reported as Archive, Encrypted / application-protected. Electron/Node's normal copyFileSync path failed with Windows error 6000 ("The specified file could not be encrypted"). This affected both:

1. relocation of the four bundled Codex executables; and
2. materialization of the bundled plugin marketplace.

The plugin package could therefore appear installed/enabled while these were still absent:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest
%USERPROFILE%\.codex\plugins\.plugin-appserver
%USERPROFILE%\.codex\chrome-native-hosts-v2.json
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Important lifecycle detail

codex plugin add chrome@openai-bundled installs the plugin payload, but it does not itself run the desktop host service that performs Chrome native-host reconciliation. In this failure state, the CLI command can return success while latest, the v2 state, manifest, and registry entry are still missing.

Recovery that worked

1. Closed Chrome/native-host processes to avoid cache locks.
2. Copied the four official OpenAI-signed runtime files to the exact runtime cache directory expected by the current build using decrypted-destination semantics (for example, robocopy /COPY:DT), then verified source/destination size, SHA-256, and Authenticode:

• codex.exe
• codex-code-mode-host.exe
• codex-command-runner.exe
• codex-windows-sandbox-setup.exe

1. Mirrored the current bundled openai-bundled marketplace to a stable user-writable directory using the same data/timestamp copy semantics, verified the complete tree, and pointed the marketplace entry at that mirror.
2. Removed/re-added chrome@openai-bundled through the supported plugin flow.
3. Triggered the desktop app's own Chrome native-host reconciliation. It then created the latest junction, .plugin-appserver, chrome-native-hosts-v2.json, native manifest, and HKCU registration.

I did not hand-write the native manifest/registry and did not run installManifest.mjs.

End-to-end verification

After repair, the real Chrome extension backend connected. I created a browser-controlled tab, navigated to https://example.com/, and read:

{
  "title": "Example Domain",
  "url": "https://example.com/",
  "snapshotContainsHeading": true
}

extension-host.exe was running from the current latest junction.

Product-side fixes suggested

• Use a decrypted-destination-capable copy fallback for both early runtime relocation and bundled marketplace materialization.
• Make install/repair transactional.
• After every desktop/plugin update, reconcile latest, v2 state, manifest, registry, and current AppX resourcesPath.
• Do not display "Connected" until a real native-host handshake succeeds.
• Surface the underlying copy/reconciliation error instead of reporting only that the app/extension is missing.