Repository navigation
[Windows] Chrome plugin clean reinstall leaves stale chrome-native-hosts-v2 entries and fails with missing codexCliPath #40357
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
- Windows/Edge: Chrome plugin update leaves locked host, partial cache, stale app-server manifest, and an uninstallable plugin #32706 — stale
chrome-native-hosts-v2.jsonwith a removedresourcesPathafter a Windows/Edge update - Windows Codex Desktop corrupts chrome@openai-bundled cache on startup when Chrome native host locks extension-host.exe #22114 — Windows file locking can leave the bundled Chrome cache partially materialized
- Windows: Chrome extension 1.2.27259.19709 rejects native host 26.814.41407 because runtimeConfig omits trustedBrowserClientSha256s #39466 — extension/native-host runtime-config mismatch involving
trustedBrowserClientSha256s - [Windows] Chrome plugin does not install native host and browser-client fails with "Cannot redefine property: process" #33408 — clean reinstall can still leave the Windows Chrome integration unusable
Activity
github-actions commentedon Aug 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zemeng5208 commentedon Aug 24, 2026
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.th3nolo commentedon Aug 30, 2026
I can confirm the same stale-target behavior on the
nodePathvariant of this error.Current reproduction (2026-08-30): Codex AppX
26.825.6671.0, ChatGPT Chrome extension1.2.27268.51612, default Windows data locations, and no data-directory migration.In
%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json, all 23 historical entries literally containpaths.nodePath; however, none of the recent targets exists anymore, and no entry was created for the current26.825runtime. Meanwhile, the current CUA Node executable exists under%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b\bin\node.exe.So the wording “missing required path” is masking the same condition described here: the property is present, but its referenced file is stale/missing. The Chrome extension is installed and enabled, and the native-host registry/JSON exist, so the failure is upstream of a browser session.
There is a second consistency break in the same installation: the bundled source advertises Browser/Chrome
26.825.51511, but the cache remains on Browser26.727.40816and Chrome26.825.32147. The normal marketplace listing omitsopenai-bundledbecause its configured source is a WSL path while the CLI is Windows-native; overriding only that source to the equivalent Windows path makes it visible immediately.Store updates, several restarts, and complete extension/Computer Use reinstalls did not reconcile either registry. This supports the proposed fix here: validate targets, regenerate the manifest atomically from the current runtime, and report “target does not exist” separately from a genuinely absent field.
svshi-gang commentedon Sep 6, 2026
Title: Possible Windows EFS interaction causing ChatGPT/Codex Chrome native-host failures
I’ve been fighting the current Windows ChatGPT/Codex Chrome integration issue for days.
My symptoms included:
Chrome integration unavailable / greyed out
extension saying the desktop app needed to be installed even though it already was
“in-app browser plugin unavailable”
missing/stale native messaging registration
stale or incomplete chrome-native-hosts-v2.json
browser runtime/plugin components failing to provision cleanly
repeated repairs/reinstalls not fixing the underlying issue
While debugging it, I noticed something completely separate: Windows had recently started showing EFS UI Application notifications asking me to back up a file-encryption certificate.
I had never intentionally enabled EFS and had never seen those notifications before.
I checked:
fsutil behavior query disableencryption
and got:
DisableEncryption = 0 (Encryption is ENABLED)
Then I ran:
cipher /u /n /h
and found EFS-encrypted files not just in WindowsApps, but also in writable Codex browser/runtime data under paths like:
C:\Users<user>\AppData\Roaming\Codex\web\Codex\Default...
including Chromium/LevelDB state, local storage, extension state, partition data, etc.
I also checked my EFS certificate with:
cipher /y
Windows had generated a new self-signed EFS certificate only a few days earlier, despite me never intentionally turning EFS on.
I then:
moved Codex back onto the system drive
decrypted the affected user/runtime files
rescanned with:
cipher /u /n /h
confirmed that normal user/Codex paths were no longer showing as EFS-encrypted
left WindowsApps, WpSystem, and package-managed files alone
disabled future EFS encryption with:
fsutil behavior set disableencryption 1
then rebooted
After that, the ChatGPT Chrome side panel started working.
I want to be very clear: I am not claiming EFS is definitely the root cause of every current Chrome/native-host failure.
But on my machine, the broken Chrome integration and unexpected EFS activation overlapped, writable Codex browser state was being encrypted, and the integration began working after I removed that condition and normalized the install/runtime location.
If you’re seeing the current Windows native-host / Chrome integration failures, I think it’s worth checking this before reinstalling Codex for the twentieth time.
Read-only checks:
fsutil behavior query disableencryption
cipher /u /n /h
cipher /y
Things that would get my attention:
C:\Users<user>\AppData\Roaming\Codex
C:\Users<user>.codex
C:\Users<user>.cache\codex-runtimes
normal Desktop/Documents/project folders
Things I would not manually decrypt or take ownership of just because they appear in the scan:
C:\Program Files\WindowsApps
:\WindowsApps
WpSystem
$RECYCLE.BIN
AppData\Local\Packages
Also, if you do find unexpected EFS encryption, back up the EFS certificate/private key before decrypting anything and do not delete that certificate until you are sure no files still depend on it.
This may be unrelated on some machines, but given how many current Windows reports involve broken native-host provisioning, stale runtime state, and missing bridge files, I think the EFS angle is worth ruling out.
colinJina commentedon Sep 15, 2026
Recurrence on Windows desktop 26.908.4834.0
I encountered the same error after updating to 26.908.4834.0, verified from the running WindowsApps package. The package contains Browser/Chrome/Computer Use 26.908.40834. Similar failures occurred after earlier updates on this installation.
On September 14, the v2 manifest still contained
paths.codexCliPath, but its target no longer existed. Its Node and resources targets were also stale. Current runtime executables existed, while the new plugin version directories were missing from the cache.Additional diagnostic evidence
Earlier affected runs on the same installation logged
bundled_plugins_marketplace_add_failedandbundled_plugins_reconcile_failedduring Desktop's automatic synchronization, with:This distinction may be relevant to #42783: these were automatic reconciliation errors, rather than a rejection from manually adding the WindowsApps source. The causal relationship to the stale manifests remains unconfirmed; these log observations are from earlier affected runs, not the September 14 run.
Recovery and limitations
After backing up and updating the bridge paths and restoring the missing caches from the installed package, native-host validation and task-side Chrome navigation passed. I also confirmed that Try again successfully opened the extension side panel after the September 14 repair.
Earlier repairs were followed by recurrence after subsequent updates. Whether this latest repair survives another update is unverified.
Environment caveat: Windows x64, ChatGPT Plus; the Codex home uses a directory junction and this installation has received manual repairs. This is not a clean-install reproducer.
Could maintainers clarify whether the automatic reconciliation failure is part of this issue or should be tracked separately under #42783?
johnnyscaler-Will commentedon Oct 8, 2026
Regression after a recent ChatGPT Windows desktop update — 2026-10-09 (UTC+8)
I am reproducing the same
codexCliPathstartup failure again after updating the ChatGPT desktop app for Windows.What happened
EPERM: operation not permitted, realpathwhen resolving%USERPROFILE%\.codex\plugins\cache\openai-bundled\computer-use\26.707.31123\scripts\computer-use-client.mjs; that earlier issue was subsequently repaired. I have not confirmed that the same EPERM error is present now.Expected: Updating the ChatGPT Windows desktop app should preserve or repair its Chrome/Edge native-host and app-server integration, so the side panels start normally.
Request: Could maintainers investigate whether the desktop updater is leaving stale/missing schema-v2
chrome-native-hosts-v2.jsonruntime entries or stale paths, and provide a supported, persistent fix instead of a temporary manual manifest repair? Please also confirm whether a currently released build fixes this update-regression. I can provide current desktop/browser/extension versions and additional sanitized diagnostics upon request.Related: #40357, #42520.