Windows: Chrome native host out of date; plugin uninstall and feedback upload fail

[mmaheregy-maker]

Chrome control is read-only. The extension setup page and tab reading work, but clicking, typing, and navigation fail with: “Codex Chrome native host is out of date.”
Chrome plugin is enabled. Its Uninstall action fails; disabling and re-enabling does not repair it. The extension-host process runs, but the Windows native-messaging registration is missing/stale.
Desktop build: 26.818.5229.0
Task ID: 01a02e26-32fc-7e63-b691-6d0c43a92df2
Please repair the Chrome native-host registration/update path and the failed plugin-uninstall behavior.

The /feedback uploader also fails repeatedly with “feedback upload failed,” both with current-session logs and browser logs selected.

[github-actions]

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

• [Windows][Chrome extension] Native host is outdated and browser control remains read-only #39531
• chrome codex #39673
• [Windows] Chrome plugin cannot connect or be uninstalled in Codex App #39723
• ChatGPT Chrome sidebar is read-only and falsely reports an outdated native host #40118

Powered by Codex Action

[zemeng5208]

I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

This report looks like a good match for one specific Windows-local layer that WinBridge is meant to diagnose: the Chrome Native Messaging bridge state, rather than Chrome page access itself.

The useful distinction here is that the extension/setup page and tab reading still work, while click/type/navigation fail with “Codex Chrome native host is out of date”. On Windows, that can be consistent with stale or incomplete local state across one or more of these layers:

• the Codex Chrome plugin cache/version and its latest target;
• the Chrome Native Host manifest installed for the current plugin/runtime;
• the corresponding HKCU NativeMessagingHosts registry entry;
• Codex's chrome-native-hosts-v2.json state, including paths that may still reference an older plugin/runtime after an update;
• partial plugin staging/uninstall state that leaves an old extension-host/native-host registration behind.

WinBridge can inspect those layers together and, where the installed official Codex package still contains healthy source files, rebuild the user-side plugin/native-host state from that package. It does not modify WindowsApps and it does not bypass Codex trust checks.

There is an important limitation: if the manifest/registry/v2 state and the active Chrome plugin/runtime are already mutually consistent, but the current Codex build is rejecting the host because of an upstream host-protocol/trust/version compatibility bug, WinBridge will not fix that. Likewise, the /feedback upload failure may be unrelated and is not something WinBridge targets.

So I would treat this mainly as a way to distinguish stale Windows Native Host/plugin state from an upstream Codex host-version/handshake regression, not as a guaranteed fix.

[mmaheregy-maker]

Read-only follow-up diagnostics using the bundled OpenAI checker confirm the registration failure:
correct: false
Native-host manifest is missing from %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension does not exist
The cached Chrome plugin files are SHA-256 identical to those bundled with Codex 26.818.5229.0
extension-host.exe is running
chrome-native-hosts-v2.json exists and references plugin/native-host version 26.818.41509
This points to a failure in the official Windows manifest/registry installation path rather than corrupted plugin files. I have not run the third-party recovery utility. Please advise on the supported way to recreate the registration and repair plugin uninstall. The separate /feedback upload failure is still reproducible.

[ofek]

I iterated on resolving this issue with Codex and finally got it working. The following is an assessment I asked it to produce with inputs from my manual testing.

---

Additional controlled reproduction and recovery on Windows with Codex Desktop 26.818.5229.0 and bundled plugins 26.818.41509.

The Chrome plugin UI initially returned Failed to uninstall plugin. After fully stopping the relevant Codex and Chrome processes, the supported CLI remove/reinstall flow repaired the Chrome-specific state:

• chrome@openai-bundled was installed and enabled at 26.818.41509.
• chrome/latest targeted 26.818.41509.
• The native-host manifest targeted chrome/latest.
• The HKCU NativeMessagingHosts registration existed.
• The Chrome extension was installed and enabled.

Chrome control nevertheless still failed before tab discovery with:

Cannot find module '%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\26.818.41509\scripts\browser-service.mjs'

The generated configuration advertised the chrome,iab backends and mapped the shared Browser service to that exact path, but browser@openai-bundled was not installed and its cache directory did not exist.

This was not an incomplete marketplace-extraction case. codex plugin list --available --json showed browser@openai-bundled version 26.818.41509 as available from the healthy openai-bundled marketplace, with installed: false and enabled: false.

Running the supported command below, then reopening Codex and testing from a fresh task, restored Chrome tab control:

codex plugin add browser@openai-bundled --json

Final verification showed:

• browser@openai-bundled 26.818.41509 installed and enabled.
• chrome@openai-bundled 26.818.41509 installed and enabled.
• The expected browser-service.mjs existed.
• The native-host registry entry existed.
• Chrome tab listing worked.

No Windows restart, registry edit, manifest edit, cache deletion, or manual native-host installation was required.

This suggests that Chrome installation/reconciliation can complete without ensuring that its required Browser runtime is installed, while runtime configuration still points unconditionally to the missing Browser service. The installer should enforce that dependency, or startup should report and repair the missing Browser plugin directly.

This also complements #26792: that report attributes missing Browser to incomplete marketplace extraction, whereas your marketplace was complete and only the installed/dependency state was wrong. I have not posted the comment.

[songluyi]

Follow-up reproduction on 2026-08-24: this remains recurrent in a fresh Codex task.

Environment:

• Windows x64
• Codex Desktop: 26.818.5229.0
• Bundled Browser/Chrome plugins: 26.818.41509
• Desktop-provided workspace dependency bundle: 26.819.11345

Observed behavior:

• Chrome discovery can briefly return the target open tab.
• The next claimTab() or chrome.tabs.list() call then hangs until the browser-control session times out and resets.
• Reconnecting repeats the same pattern, so browser work cannot proceed reliably.
• This recurrence interrupts authenticated browser workflows and costs several minutes each time.

Read-only bundled diagnostics:

• Google Chrome is installed.
• check-native-host-manifest.js --browser chrome --json reports exists: false, correct: false.
• The native-host manifest is missing from %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json.
• HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension is absent.
• check-extension-installed.js --browser chrome --json cannot find the expected Chrome user-data directory.
• Both Browser and Chrome plugin cache directories exist, but the control bridge is not reconciled automatically.

This looks consistent with version/dependency reconciliation or native-host registration being lost across Codex/plugin updates, rather than a target-site or WordPress problem.

Requested product fix:

1. On startup/update, automatically validate Browser ↔ Chrome plugin version compatibility and native-host registration.
2. Recreate the official manifest/HKCU registration when missing, or provide a supported one-click repair.
3. Detect this state before a task starts instead of allowing tab discovery followed by a long timeout.
4. Preserve authenticated Chrome tabs and avoid requiring users to reinstall the integration repeatedly.

[jurajmichalak1]

My solution for the "Chrome control is unavailable—the Codex Chrome native host is out of date. Please update or reinstall the Codex Chrome plugin" problem (in response message from ChatGPT chrome extension in side panel chat):
Start new chat and before requesting any work send this request:

Use Chrome computer control.
Initialize the Chrome browser-control runtime and run
agent.browsers.list().
Do not use getTabContext as a substitute.

It initializes chrome browser control and then you can send all your request for interaction with your current chrome tab.

I have Windows 11 with Chrome and Ubuntu with Chrome with multiple development Chrome profiles on oeach machine and Chrome extension was not able to preform "write" browser-control. Only "read" browser tab was working. This hack helped me on both envs (Win and GNU/Linux). You have to start each chat with that message.

[EslamAbdElhakem]

@jurajmichalak1 Thanks, it’s working now.