[Windows] Chrome plugin clean reinstall leaves stale chrome-native-hosts-v2 entries and fails with missing codexCliPath

Open 💬 2 comments Opened Aug 24, 2026 by sweetheadcc-rgb
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

[Windows] Chrome plugin clean reinstall leaves stale chrome-native-hosts-v2 entries and fails with missing codexCliPath

Summary

On Windows, removing and re-adding the bundled Chrome plugin from Codex, reinstalling the Chrome extension, and restarting both applications did not refresh all Chrome native-host state.

The Chrome side panel repeatedly showed:

Unable to start ChatGPT
Codex app-server manifest entry is missing required path codexCliPath

The native messaging registry key and JSON manifest existed, but the install was split across stale and current state. The decisive remaining failure was two stale chrome-native-hosts-v2.json files whose entries pointed to Codex/Node binaries removed by earlier desktop updates.

After backing up and rebuilding both v2 manifest files with current, existing runtime paths, the native-host codexRuntime/hello and codexRuntime/ensure calls succeeded and the user confirmed the Chrome side panel connected.

Environment

  • Windows: 10.0.26200.9168 x64 (25H2)
  • Google Chrome: 151.0.7922.170
  • Codex AppX: 26.818.5229.0
  • Codex CLI: 0.149.0-alpha.4.1
  • ChatGPT Chrome extension: 1.2.27268.51612
  • Bundled Chrome plugin found locally: 26.707.31123
  • Bundled Browser plugin found locally: 26.818.21641
  • Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Native host: com.openai.codexextension

User-specific paths, tokens, account identifiers, and runtime session IDs are omitted.

Steps that reproduced the failure

  1. Use the official Codex Windows desktop app.
  2. Remove the Chrome plugin from the Codex Plugins UI.
  3. Fully close Chrome and confirm chrome.exe and extension-host.exe have exited.
  4. Restart Codex and re-add the Chrome plugin.
  5. Let the setup flow open Chrome and install/enable the official ChatGPT extension.
  6. Close Chrome again, restart Codex while Chrome is closed, then reopen Chrome.
  7. Open the ChatGPT side panel.

The side panel still reported that codexCliPath was missing. Repeating the supported remove/re-add/reinstall flow did not change the error.

State observed before manual repair

Native messaging registration existed

The registry key existed:

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

It pointed to:

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

The JSON manifest pointed to:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

Plugin/cache state was incomplete or stale

  • The Chrome cache contained only 26.707.31123.
  • The latest junction was absent.
  • extension-host-config.json was absent.
  • The bundled Chrome marketplace snapshot was also 26.707.31123, while the installed desktop and Browser bundle were 26.818.*.

Recreating latest and running the plugin's own installManifest.mjs produced a valid schema-v1 host config containing current codexCliPath, nodePath, nodeReplPath, and browserClientPath. All paths existed, but the side panel still showed the same codexCliPath error.

The actual remaining blocker was the schema-v2 app-server manifest

Both of these files existed but contained only old entries from a previous desktop installation:

%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
%USERPROFILE%\.codex\chrome-native-hosts-v2.json

The entries did contain a paths.codexCliPath property, but it referenced an old hashed Codex binary directory that no longer existed. Their Node, node-repl, and AppX resources paths were stale as well.

The extension maps native-host required_path_missing to manifest_required_field_invalid, producing the user-facing message that the entry is “missing required path codexCliPath.” In this case the property was present; its target did not exist.

Diagnostic repair and verification

This was an unsupported, reversible diagnostic repair, not a recommended end-user workflow:

  1. Back up native-host manifests and both v2 app-server manifests.
  2. Restore chrome/latest to the complete immutable versioned cache directory.
  3. Run the bundled manifest installer with the current Codex/Node/node-repl paths.
  4. Replace stale v2 entries with one current entry whose required paths all exist.
  5. Include the SHA-256 of the selected browser-client.mjs in trustedBrowserClientSha256s.
  6. Stop the old extension-host.exe so Chrome launches a fresh process.

A direct length-prefixed Native Messaging diagnostic then returned:

codexRuntime/hello:
  manifestSchemaVersion: 2
  nativeHostProtocolVersion: 2
  supportedProtocolVersions: [2]

codexRuntime/ensure:
  selected: current repaired entry
  runtimeConfig.codexCliPath: current existing Codex binary
  runtimeConfig.nodePath: current existing Node binary
  runtimeConfig.nodeReplPath: current existing node-repl binary
  runtimeConfig.trustedBrowserClientSha256s: [current browser-client SHA-256]

No WebSocket token or runtime session ID is included here.

After reopening the side panel, the user confirmed that it connected successfully.

Expected behavior

Removing/re-adding or repairing the Chrome plugin should update these components as one recoverable transaction:

  • immutable versioned Chrome plugin cache;
  • chrome/latest junction;
  • native messaging JSON and registry registration;
  • schema-v1 extension-host-config.json;
  • both schema-v2 chrome-native-hosts-v2.json locations;
  • current Codex, Node, node-repl, resources, and browser-client trust data.

Before an entry becomes active, every required path should be validated with an existence/access check. A property whose target no longer exists should be reported as a stale path, not a missing field.

The supported UI reinstall flow should remove or replace incompatible stale v2 entries instead of preserving them across desktop updates.

Related reports

  • #32706 — stale chrome-native-hosts-v2.json with a removed resourcesPath after a Windows/Edge update
  • #22114 — Windows file locking can leave the bundled Chrome cache partially materialized
  • #39466 — extension/native-host runtime-config mismatch involving trustedBrowserClientSha256s
  • #33408 — clean reinstall can still leave the Windows Chrome integration unusable

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 days ago

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

  • #40228

Powered by Codex Action

zemeng5208 · 4 days ago

I maintain WinBridge Recovery. This report is a strong match for the local Windows state that WinBridge is intended to diagnose and, where possible, reconstruct: the bundled Chrome cache/version/latest pointer, the Native Messaging manifest + HKCU registration, extension-host-config.json, and especially the schema-v2 chrome-native-hosts-v2.json entries whose codexCliPath / Node / node-repl / resources paths can survive an app update and point at removed versioned locations.

In this specific failure mode, WinBridge can help distinguish “the extension/native host is missing” from “the host is registered but its per-user v2 runtime state is stale”, validate that every referenced path actually exists, compare the active Chrome plugin version with the installed MSIX/bundled marketplace state, and rebuild the recoverable per-user integration layer from the currently installed package rather than from an older cache snapshot.

The important limitation is that this only addresses local state drift/corruption. If a clean, internally consistent v2 manifest generated from the current package is later overwritten with stale paths again, or if the current Codex build itself emits/consumes the wrong schema/protocol/trust data, that is an upstream update/manifest-generation bug and WinBridge cannot guarantee a durable fix. It does not modify files inside WindowsApps and should not be treated as a replacement for the product-side fix requested here.