openai / openai/codex

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

Open
#40,357 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server browser bug windows-os
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.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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.