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

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.

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

Powered by Codex Action

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.

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.

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.

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:

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

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.

@jurajmichalak1

@jurajmichalak1 Thanks, it’s working now.

Reproduced on Windows with OpenAI.Codex 26.825.3734.0 and the official ChatGPT Chrome extension 1.2.27268.51612 (extension ID hehggadaopoacecdllhhajmbjkdcmajg).

The Chrome side panel can identify and read the active Wikipedia tab, but clicking, typing, and navigation are unavailable and the session reports that the Codex Chrome native host is out of date.

Verified locally:

Only one OpenAI.Codex AppX package is installed.
Only one com.openai.codexextension native-messaging registration exists.
The registered manifest and extension-host.exe both exist.
The host points to %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe.
The extension is installed once in Chrome’s Default profile.
The extension manifest and native host were recreated within approximately one minute of each other on 2026-08-28.
Full Chrome/Codex restarts, a fresh side-panel chat, and extension reinstall did not resolve the failure.
Desktop Work with @Chrome successfully clicked the same Chrome/Wikipedia tab, so the base Chrome-control path works; only the side-panel interactive-control path fails.

This appears closely related to the stale schema-v2 runtime state described in #40357, or to the capability-discovery/handshake failure described in #39972. Please expose the selected schema-v2 runtime entry and exact rejected capability instead of returning the generic “native host is out of date” message.

Root cause isolated: `codexRuntime/status` drops the runtime config returned by `ensure`

Why this is a new root fix, not another recovery recipe: this failure was reported repeatedly across multiple desktop/plugin generations. Earlier reports established the read-only/out-of-date symptom, registration drift, and restart/reinstall recoveries. The duplicate and PR searches performed before publication found no previous public analysis that identified the successful codexRuntime/status response as the point where runtimeConfig.browserClientPath is discarded, and no prior public fix that redirected that path to the existing full ensure handler. The result below is a controlled binary root fix with cold-start end-to-end verification.

I reproduced the Windows Chrome side-panel failure on a current, internally consistent installation where the native-host manifest, registered executable, plugin cache, and browser client all existed and matched. Direct browser control worked when initialized explicitly, but fresh side-panel tasks still received browserClientPath = null and incorrectly fell back to “native host is out of date.”

Root cause

Protocol and static analysis show two different successful response paths in the installed extension-host.exe:

codexRuntime/ensure is idempotent and returns the existing runtime session plus the full runtimeConfig, including browserClientPath.
codexRuntime/status returns only phase and runtimeSessionId.

The side-panel capability handoff can therefore lose a previously valid browser-client path after a status/reconnect and construct the task with browserClientPath = null, even though the host and client are current and usable.

Minimal root fix validated locally

The successful status branch in the native-host executable was redirected to the existing full ensure handler. This did modify extension-host.exe through the six-byte branch patch below; no Chrome extension source code, manifest-selection logic, or native-host lifecycle logic was changed.

Status-method branch: RVA 0x3D364
Former reduced serializer: RVA 0x3D55D
Existing full ensure handler: RVA 0x3D399
Branch bytes: 0F 84 F3 01 00 00 → 0F 84 2F 00 00 00
Patched extension-host.exe SHA-256: 0ca4bcc1cefe06b74cd3e79b88a2b1c63684f630bfabb00157db4ece6788efd0

Maintainer handoff: source-level implementation

The production fix should preserve these invariants rather than copy the tested RVA:

A successful codexRuntime/status response must include the same complete runtimeConfig contract as a successful idempotent codexRuntime/ensure, including browserClientPath.
A status/reconnect must never replace a known valid runtime configuration with a reduced object.
Before constructing side-panel task capability metadata, the producer must preserve the last full ensure result or re-fetch the full configuration.
The generic “native host is out of date” result must be reserved for an actual compatibility failure, not a missing field caused by the status serializer.

Required regression tests:

ensure -> status -> status keeps one runtime session and the same non-null browser-client path.
Cold start followed by status-only reconnect still produces a complete task capability context.
A valid current host/client pair never emits the outdated-host fallback.
A genuinely invalid or incompatible host still fails normally.

Verification

A controlled isolated-manifest test ran status -> status -> ensure. All three calls returned the same runtime session and the same valid browser-client path. After installing the patched host and cold-starting Chrome, a brand-new side-panel task completed the full control path: click, modal open, scroll, focus, type, select, delete, close, and cleanup. The false “native host is out of date” fallback did not recur.

Environment used for the final verification:

Windows 11
Bundled Chrome/browser generation: 26.825.32147
Chrome extension: 1.2.27268.51612
Chrome Stable: 152.0.7977.65
Chrome Beta: 153.0.8010.12

Public implementation reference

This comment is the canonical public patch specification for this root cause. The RVAs, bytes, and hashes identify the exact artifacts used for verification; they are evidence, not portable patch addresses. Anyone porting the fix to a newer generation should implement the source-level invariants and run the regression tests above rather than apply offsets blindly. No installed executable is required to understand or reproduce the repair.

Related validated root-fix specifications:

Chrome native-host status/ensure: Windows: Chrome native host out of date; plugin uninstall and feedback upload fail #40228 (comment)
Windows Computer Use UIA/geometry/focus/synchronization: Computer Use cannot determine Chrome URL on Windows, even on chrome://newtab/ #25271 (comment)
Windows Computer Use rotated native pipe: [Windows] Computer Use retains a rotated native-pipe UUID and never reconnects #41453

No executable, installed binary, user path, account data, task/tab identifier, or token is attached. The repository contribution rules ask for root-cause analysis in issues and do not accept external PRs, so I am posting the implementation-level diagnosis here rather than opening a PR.

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.

Additional Windows reproduction (2026-09-24): the Codex desktop app is on 26.917.62051, but the Chrome Native Messaging manifest for com.openai.codexextension still points to extension-host.exe under the removed 26.915.4065.0 app version. The Chrome extension is installed/enabled and browser permissions are granted; Codex's browser runtime exposes only the in-app browser (iab), not Chrome. This is stale update-time host registration, distinct from a site-permission problem or a missing extension. Please make the app update path detect and repair a manifest/registration target that refers to a removed prior app version, and add a regression test across consecutive Windows desktop updates. No credentials, account identifiers, or private paths are included here.

Navigation Menu

Repository navigation

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

Root cause isolated: `codexRuntime/status` drops the runtime config returned by `ensure`

Root cause

Minimal root fix validated locally

Maintainer handoff: source-level implementation

Verification

Public implementation reference

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

github-actions commented on Aug 23, 2026

zemeng5208 commented on Aug 23, 2026

mmaheregy-maker commented on Aug 23, 2026

ofek commented on Aug 24, 2026

songluyi commented on Aug 24, 2026

jurajmichalak1 commented on Aug 27, 2026

EslamAbdElhakem commented on Aug 27, 2026

fizzjin8823-creator commented on Aug 28, 2026

search620 commented on Aug 29, 2026

Root cause isolated: codexRuntime/status drops the runtime config returned by ensure

Root cause

Minimal root fix validated locally

Maintainer handoff: source-level implementation

Verification

Public implementation reference

svshi-gang commented on Sep 6, 2026

daisukekubota0823 commented on Sep 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Root cause isolated: `codexRuntime/status` drops the runtime config returned by `ensure`