[Windows] Chrome plugin clean reinstall leaves stale chrome-native-hosts-v2 entries and fails with missing codexCliPath
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
[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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the supported Windows Chrome plugin remove/re-add flow and the bundled installManifest.mjs, then follow how it updates chrome/latest, extension-host-config.json, and both chrome-native-hosts-v2.json files. Verify how required paths are selected and validated before native-host startup. Done means reinstalling replaces stale v2 entries and the Chrome side panel connects without the misleading missing codexCliPath error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, nodejs, rust
- Domain
- desktop, devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100