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

Activity

1. 2474036039

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 13, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   browser

   on Jul 13, 2026
3. github-actions commented on Jul 13, 2026

   

   github-actionsBot

   on Jul 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Chrome extension reports app not installed because native-host manifest points to stale plugin link on macOS #31904

   Powered by Codex Action
4. ULing19 commented on Jul 13, 2026

   

   ULing19

   on Jul 13, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   👀React with 👀1Reacted by Hong Zhang
5. ULing19 commented on Jul 13, 2026

   

   ULing19

   on Jul 13, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   🚀React with 🚀1Reacted by Hong Zhang
6. braden-sanders-stoneage commented on Jul 15, 2026

   

   braden-sanders-stoneage

   on Jul 15, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. braden-sanders-stoneage commented on Jul 15, 2026

   

   braden-sanders-stoneage

   on Jul 15, 2026 – with ChatGPT Codex Connector

   More actions

   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.
8. FeyZha commented on Jul 18, 2026

   

   FeyZha

   on Jul 18, 2026 – with ChatGPT Codex Connector

   More actions

   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
   3. 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.
   4. Removed/re-added chrome@openai-bundled through the supported plugin flow.
   5. 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.
9. zemeng5208 commented on Aug 12, 2026

   

   zemeng5208

   on Aug 12, 2026 – with ChatGPT Codex Connector

   More actions

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

   The diagnostics in this thread are especially useful because they show that a missing Native Messaging Host can be a downstream symptom rather than the first failure: the plugin payload is installed, but protected WindowsApps runtime relocation fails before Desktop ever reaches native-host reconciliation.

   That distinction is something WinBridge Recovery should preserve. The safe recovery sequence is not “write the registry key because it is missing”; it is: resolve the current official package, validate/materialize the required official runtime/plugin files into the expected user-side locations, verify size/hash/signature, then let Codex Desktop perform its own host reconciliation and finally verify the manifest/HKCU/v2 state/.plugin-appserver outputs.

   The project already focuses on backup + version-aware user-side recovery and avoids taking ownership of or modifying WindowsApps. I’m also taking the self-heal design described here as useful implementation guidance: verified staging, fail-safe rollback, mutex/overlap protection and a last-known-good state are much safer than repeated destructive cleanup.

   This is still an independent recovery tool, not a replacement for fixing the protected-copy path in Codex itself.
10. violetta03-dreamer commented on Aug 14, 2026

    

    violetta03-dreamer

    on Aug 14, 2026 – with ChatGPT Codex Connector

    More actions

    Still affected on the same Windows machine after Codex desktop updates.

    Current state:

    • Codex AppX: 26.810.4967.0
    • Chrome integration remains unusable and the current Codex session does not expose a Chrome plugin/backend.

    The last layer-by-layer diagnostic on this machine, while the official Chrome extension was installed and enabled in Profile 3, showed:

    • Native-host manifest missing: %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    • Registry key missing: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
    • Activation error: manual_plugin_install_failed: Missing bundled Electron runtime required to sync Chrome native host resources for com.openai.codexextension
    • Source executables in the Windows Store package were marked Encrypted; disk space and destination permissions were normal.

    No manifest or registry key was created manually.

    For completeness, this machine also reproduces the separate Computer Use harness regression tracked in #34039; I am not assuming the two failures have the same root cause.

    OpenAI feedback ID: 019fc892-c10b-7cb0-b58d-6514ec611921.

    Could a maintainer confirm whether the Chrome native-host installation/repair path is being tracked in this issue?