[Windows] Chrome plugin clean reinstall leaves stale chrome-native-hosts-v2 entries and fails with missing codexCliPath
[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.9168x64 (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
- Use the official Codex Windows desktop app.
- Remove the Chrome plugin from the Codex Plugins UI.
- Fully close Chrome and confirm
chrome.exeandextension-host.exehave exited. - Restart Codex and re-add the Chrome plugin.
- Let the setup flow open Chrome and install/enable the official ChatGPT extension.
- Close Chrome again, restart Codex while Chrome is closed, then reopen Chrome.
- 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
latestjunction was absent. extension-host-config.jsonwas absent.- The bundled Chrome marketplace snapshot was also
26.707.31123, while the installed desktop and Browser bundle were26.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:
- Back up native-host manifests and both v2 app-server manifests.
- Restore
chrome/latestto the complete immutable versioned cache directory. - Run the bundled manifest installer with the current Codex/Node/node-repl paths.
- Replace stale v2 entries with one current entry whose required paths all exist.
- Include the SHA-256 of the selected
browser-client.mjsintrustedBrowserClientSha256s. - Stop the old
extension-host.exeso 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/latestjunction;- native messaging JSON and registry registration;
- schema-v1
extension-host-config.json; - both schema-v2
chrome-native-hosts-v2.jsonlocations; - 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.jsonwith a removedresourcesPathafter 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
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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/
latestpointer, the Native Messaging manifest + HKCU registration,extension-host-config.json, and especially the schema-v2chrome-native-hosts-v2.jsonentries whosecodexCliPath/ 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
WindowsAppsand should not be treated as a replacement for the product-side fix requested here.