Windows/Edge: Chrome plugin update leaves locked host, partial cache, stale app-server manifest, and an uninstallable plugin

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

• #31904

Powered by Codex Action

Resolution update: clean uninstall/reinstall restored the integration

The user completed the reinstall, and the resulting state has now been verified locally.

Additional lock source found during uninstall

Stopping extension-host.exe alone was not enough. The Codex browser diagnostic session had also loaded a native classic-level module from the Chrome plugin cache. Resetting the diagnostic session did not terminate all of its child node.exe processes, so codex plugin remove chrome@openai-bundled continued to fail with Windows error 5 (Access is denied).

After identifying and stopping only the Codex diagnostic Node children associated with that browser session, the official CLI uninstall succeeded:

• Plugin state: not installed
• Chrome plugin cache: absent
• Running extension-host.exe: 0

This suggests uninstall/update should also terminate or detach browser-client/Node processes that have native modules loaded from the plugin cache, not only the native extension host.

Recovery sequence that worked

1. Temporarily disable the Codex extension in Edge.
2. Stop the plugin-owned extension-host.exe.
3. Stop only Codex browser diagnostic Node children that loaded modules from the Chrome plugin cache.
4. Run codex plugin remove chrome@openai-bundled.
5. Fully restart Codex.
6. Reinstall the Chrome plugin from Codex.
7. Re-enable the Edge extension.

A stale chrome-native-hosts-v2.json had been backed up and removed before restart. Codex then regenerated it correctly during the clean reinstall.

Post-reinstall verification

• Plugin: installed and enabled, version 26.707.61608
• Version cache: 375 files
• Required content present:
• docs/
• .codex-plugin/plugin.json
• scripts/browser-client.mjs
• extension-host/windows/x64/extension-host.exe
• latest junction targets 26.707.61608
• Native Messaging manifest targets the current 26.707.61608 host
• chrome-native-hosts-v2.json now reports:
• app/plugin/CLI version 26.707.61608
• resourcesPath pointing to the currently installed AppX OpenAI.Codex_26.707.8168.0
• The regenerated resourcesPath exists
• The running extension-host.exe comes from the current plugin cache

The user reports the browser integration is functioning normally again.

Product implication

The update/remove lifecycle should account for every process that can load files from the plugin cache:

1. extension native host;
2. browser-client diagnostic Node workers;
3. any app-server process holding plugin-native dependencies.

The product should stop/detach these processes before deletion, stage and validate the new cache atomically, then update latest, Native Messaging registration, and the app-server manifest together.

Additional reproduction on Google Chrome and a newer Windows build

I can reproduce a closely related stale-state failure on Codex Desktop for Windows.

Sanitized environment

• Codex Desktop: 26.715.2305.0
• Complete bundled Chrome plugin cache generated: 26.715.21425
• Stale registered plugin version: 26.707.62119
• Browser: Google Chrome with the Codex extension installed and enabled

Observed state

1. The current cache at %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.715.21425 is complete. It contains .codex-plugin/plugin.json, assets, scripts/browser-client.mjs, and extension-host.exe.
2. The latest junction still points to the missing directory 26.707.62119.
3. %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json also points to the missing 26.707.62119\...\extension-host.exe.
4. Google Chrome and extension-host.exe were fully closed, then Codex Desktop was restarted. The current plugin directory was regenerated successfully, but the stale latest junction and native-host manifest were not reconciled.
5. Removing the bundled plugin still fails both by display name (Chrome) and exact ID (chrome@openai-bundled). At the time of these attempts, there were zero chrome.exe and zero extension-host.exe processes. The UI/API returned only a generic Failed to uninstall plugin result.

Expected behavior

• Startup reconciliation should atomically switch latest to the complete current plugin version.
• The native-host manifest should be regenerated to point to the current extension-host.exe.
• Remove/re-add should either succeed or report the exact lock/path/process preventing cleanup instead of returning a generic uninstall failure.

No manual registry or native-host modifications were made.

One additional recovery condition from a closely related reproduction on Codex Desktop 26.715.4045.0 / Chrome plugin 26.715.31925.

After the complete current plugin version existed, the following could still remain absent or stale:

• chrome/latest
• .plugin-appserver
• chrome-native-hosts-v2.json
• the Native Messaging manifest/registry entry

There were two independent blockers:

1. Chrome/extension-host.exe or diagnostic Node workers holding plugin-cache files; and
2. WindowsApps files marked Archive, Encrypted, causing Electron/Node copy operations to fail with Windows error 6000.

After closing the plugin-owned processes, I copied the official signed runtime files and bundled marketplace to verified user-writable cache/mirror locations using decrypted-destination semantics (robocopy /COPY:DT), then used the supported plugin install flow. The desktop app's own native-host reconciliation was then able to atomically point latest at the current version and regenerate the v2 state, manifest, and HKCU registration.

A useful diagnostic distinction: codex plugin add succeeding only proves the payload install completed. It does not prove that desktop native-host reconciliation ran. Verify the junction, v2 entry, manifest target, registry value, current AppX resourcesPath, and an actual browser handshake.

The real Chrome extension backend subsequently created a tab, navigated to https://example.com/, and read the page successfully. No manual manifest/registry fabrication was used.

This reinforces the need for update/remove to stop every plugin-cache consumer, stage/validate atomically, and reconcile all host state after each AppX/plugin version change.

Additional deterministic reproduction on a newer Windows build.

Environment:

• Codex Desktop AppX: 26.727.4816.0
• Chrome plugin: 26.721.31836
• Platform: Windows x64

The supported plugin uninstall path returns only Failed to uninstall plugin, but it is not a no-op. It partially deletes the cache:

• Complete same-version source/cache: 376 files
• Cache after the failed uninstall: 342 files
• Exactly 34 files are removed, comprising .codex-plugin/, assets/, and docs/
• extension-host/, scripts/, and skills/ remain
• The next plugin load reports failed to load plugin: missing or invalid plugin.json

Restoring the three missing directories from the bundled same-version source returned the cache to 376 files, with matching SHA-256 hashes and zero changed/extra files. Retrying the supported uninstall reproduced the same 376 -> 342 partial deletion and generic failure.

This shows the uninstall operation is non-transactional on this build: it mutates the installed cache before failing and leaves the plugin marked/configured in a broken half-installed state. No registry or native-host files were manually modified.

Additional reproduction: AppX physically installed on a secondary encrypted drive

I encountered the same user-visible error on Windows x64 with Google Chrome:

Unable to start ChatGPT
Codex app-server manifest entry is missing required path resourcesPath

Environment

• ChatGPT/Codex AppX: 26.727.6591.0
• Bundled Codex/Chrome plugin build: 26.727.51351
• Browser: Google Chrome with the ChatGPT/Codex extension installed

Observed state

• Installing the Chrome plugin produced a Failed to install plugin notification.
• Returning to the Plugins page then showed Chrome as installed, even though the sidebar still could not start ChatGPT.
• Get-AppxPackage reported a compatibility path under C:\Program Files\WindowsApps\OpenAI.Codex_....
• That C: path was a junction targeting the physical package under D:\WindowsApps\OpenAI.Codex_....
• Windows Settings → Installed apps → ChatGPT → Move independently confirmed the app was installed on D:.
• The physical D: package had Directory, Archive, Encrypted attributes.

Recovery and verification

I used the supported Windows Move action to move ChatGPT from D: to OS (C:), then restarted it. After the move:

• the AppX path on C: was a direct directory rather than a junction to D:;
• the Chrome plugin cache was unencrypted;
• the native-host manifest and HKCU Native Messaging registration resolved to an existing extension-host.exe; and
• the Chrome backend connected successfully and enumerated the live Chrome tabs.

Moving the AppX may also have forced stale registration state to regenerate, so the secondary-drive/encryption condition is a strong correlation rather than proof of the sole cause. Still, Move to C: was the change that turned this reproduction from broken to working.

OpenAI feedback ID: 019fcdba-0bf9-70e0-a623-764b48dd6dc6

Author disclosure: I maintain WinBridge Recovery, an independent Windows recovery project for Codex Desktop.

This report is particularly relevant to the state the tool checks: a versioned plugin cache can be incomplete while latest, the native-host registration, and the currently installed AppX resources point at different generations. WinBridge Recovery resolves the currently installed official Codex package, checks those version/path relationships, detects stale/partial user-side state, and repairs only the inconsistent pieces with backup/rollback support.

I’m sharing it here as a possible recovery aid for users who hit this specific cache/pointer/registration drift after an update, not as a claim that it fixes the underlying updater race. It does not modify WindowsApps contents, bypass file locks by changing ownership, or weaken sandbox/security policy. If the failure is caused by a product runtime bug rather than stale local state, it deliberately leaves that outside its scope.

I am experiencing the same Windows Chrome native-host failure.

Feedback ID:
no-active-thread-01a01f0b-2a7b-7a53-aa74-263206d90512

Environment:

• ChatGPT/Codex desktop app: 26.818.2441.0
• Chrome extension: 1.2.27267.15375
• Bundled Chrome plugin: 26.818.21641
• Chrome: 151.0.7922.170

The side panel loads and can read the selected tab, but tab enumeration, navigation and control remain unavailable. The extension reports that the Codex Chrome native host is out of date.

A clean app/extension/plugin reinstall, regenerated native-host configuration, corrected resourcesPath and nodePath, and a full restart did not resolve it.

Additional reproduction on Windows, August 20, 2026.

Incident timestamp: August 20, 2026 at 10:18 AM EDT (America/New_York)

This appears to reproduce the same update-time state divergence described in this issue, with a newer Codex build.

Environment

• Windows
• Current installed Codex AppX: 26.814.5517.0
• Current install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0
• Official ChatGPT Chrome extension was installed from the Chrome Web Store
• Chrome extension version observed before reinstall: 1.2.27267.15375
• Chrome plugin cache observed before repair: 26.803.81509

Failure sequence observed

1. ChatGPT Chrome sidebar failed with:

Unable to start ChatGPT
Codex app-server manifest entry is missing required path resourcesPath

1. The native messaging manifest existed and pointed to a real extension-host.exe.
2. C:\Users\Ryan\.codex\chrome-native-hosts-v2.json contained two stale runtime entries referencing older removed AppX resource directories:

• OpenAI.Codex_26.803.8161.0...\app\resources
• OpenAI.Codex_26.803.10989.0...\app\resources

1. The current valid resources path was verified with PowerShell Test-Path as:

C:\Program Files\WindowsApps\OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0\app\resources

1. After backing up the JSON and updating both stale resourcesPath values to the current verified AppX resources directory, the error changed to:

Codex app-server manifest entry is missing required path nodePath

1. The official ChatGPT Chrome extension was then completely removed and reinstalled.
2. The stale local Chrome plugin cache C:\Users\Ryan\.codex\plugins\cache\openai-bundled\chrome\latest was renamed out of the way so Codex could regenerate it on restart.
3. After restart/reinitialization, the sidebar loaded far enough to report that Chrome control was unavailable because the Codex Chrome native host was out of date.
4. At approximately 10:18 AM EDT, the sidebar began glitching again rather than returning to a stable working state.

Impact

The Chrome sidebar is used for active production workflows and browser-control tasks. The failure blocks or degrades access to the user's existing logged-in Chrome state and interrupts those workflows.

Additional observation

The failure mode changes as individual stale paths are repaired, suggesting the AppX version, plugin cache, native host, Node runtime paths, and app-server manifest are not being regenerated/validated atomically after an update.

This also appears related to #39531, which reports the native host remaining outdated/read-only on the same current ChatGPT/Codex desktop version 26.814.5517.0.

A product-side self-heal that rebuilds all version-specific paths (resourcesPath, nodePath, host paths, cache/junction state) together after an AppX update would likely prevent this class of failure.

Clean reproduction after complete removal and reinstall:

Windows ChatGPT app: 26.818.2441.0
Bundled Chrome plugin: 26.818.21641
Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Verified:

• Fresh AppX installation
• Fresh plugin and extension installation
• nodePath exists
• resourcesPath exists and matches the installed AppX
• Native-host registry and manifest exist
• extension-host.exe launches and remains running
• Correct extension origin is authorised

Result:
Selected-tab text works, but tab enumeration/navigation/control fails with:
“Codex Chrome native host is out of date.”

Feedback ID:
no-active-thread-01a01f0b-2a7b-7a53-aa74-263206d90512

Additional recurrence on the same Windows/Chrome integration failure.

Incident timestamp: August 20, 2026 at 12:37 PM EDT (America/New_York)

The ChatGPT Chrome sidebar froze again while attempting to resume a production Active Listings audit after the earlier native-host / manifest repairs documented above.

What was happening when it froze

The sidebar had been given a continuation handoff to run a full manual August 20 combined STATUS + PRICE audit against a SharePoint production workbook containing roughly 1,829 active properties. The audit is designed to research current listing status and current asking price, then write a single reconciled result back to the exact production workbook.

Verified impact of this freeze

After the sidebar froze, the production workbook was re-fetched directly from SharePoint to determine whether any safe checkpoint had been committed.

Findings:

• Production workbook last modified: August 20, 2026 at approximately 9:59 AM EDT.
• AuditControlTable still shows the prior August 17 run as Incomplete, ErrorCount 4, RunID AUDIT-20260817-094224-ET.
• AuditRunLog contains no August 20 audit run entry at all.
• PriceTrackingTable still carries prior-day / August 19 baseline/check state and no August 20 completed price-lane run.
• No authoritative production checkpoint exists for the resumed August 20 audit.

Because the sidebar froze before a run-control/log write was committed, any live browser research it had already performed cannot be trusted as resumable state. The next sidebar session must re-fetch the workbook and restart the full audit from a clean current-state baseline to avoid partial or duplicate writeback.

Why this matters for usage / credits

This is now forcing repeated execution of a large, research-heavy workflow. A single failed sidebar session can require the next session to redo substantial browser research across a large active-property population because no durable checkpoint survives the freeze. That repeated research is a plausible contributor to unusually high weekly Codex usage and is materially disruptive to production work.

This recurrence should be considered part of the same lifecycle/state-divergence problem: after update/repair, the sidebar can still degrade or freeze during real browser-control work rather than returning to a stable, self-healed state.

Additional Windows/Google Chrome reproduction: stale resourcesPath, recovery-path package mismatch, and verified recovery

I hit a closely related failure on Windows with Google Chrome and collected a read-only forensic trace before repair. This reproduction adds a recovery-path case where the Codex package itself was removed and a subsequent ChatGPT-branded install installed ChatGPT Classic (OpenAI.ChatGPT-Desktop) rather than restoring OpenAI.Codex.

Failure sequence

1. Codex browser control could enumerate/see Chrome state but could not safely attach to the target tab.
2. The Chrome extension was installed/enabled. The native-host manifest existed, while native-host registration/provisioning was initially inconsistent during troubleshooting.
3. Browser plugin uninstall initially returned the generic Failed to uninstall plugin result. A later reinstall reported success, but browser control still failed.
4. Windows app Repair was attempted. AppX deployment logs later showed both repair attempts had actually failed with 0x80073D02 because OpenAI.Codex was still running.
5. OpenAI.Codex_26.814.5517.0 was then successfully removed.
6. The subsequent Windows install installed OpenAI.ChatGPT-Desktop 1.2026.190.0 (display name ChatGPT Classic) instead of restoring OpenAI.Codex. That package contained no Codex binaries/app-server resources.
7. chrome-native-hosts-v2.json still referenced the removed Codex package:

...\OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0\app\resources

Test-Path on that resourcesPath was false, while every other path in the manifest entry existed.

1. The resulting UI error was:

Unable to start ChatGPT
Codex app-server manifest entry is missing required path resourcesPath

The error strings and required_path_missing enum were also found in the active extension-host.exe binary. At this point Chrome native messaging itself was demonstrably reaching extension-host.exe; the missing Codex package/resources path was the blocker.

Correct-package recovery

Installing/opening the current non-Classic ChatGPT/Codex application restored:

OpenAI.Codex 26.818.2872.0

with a populated:

...\OpenAI.Codex_26.818.2872.0_x64__2p2nqsd0c76g0\app\resources

The Chrome plugin cache regenerated to 26.818.22352; latest repointed to that build; both copies of chrome-native-hosts-v2.json became byte-identical and gained a new valid entry whose resourcesPath resolves to the current OpenAI.Codex_26.818.2872.0 package. Native Messaging registration and com.openai.codexextension.json were valid.

One noteworthy residual state: the regenerated v2 manifest retained the old stale entry for 26.814.41957 / removed OpenAI.Codex_26.814.5517.0 alongside the new valid entry. The old entry has a dead presence.pid; the new entry has a live app PID. So startup/self-healing added a valid entry but did not purge the dangling one.

Live post-recovery validation

After restarting Chrome so the pre-repair extension-host.exe could not serve the test, a trivial Codex browser task succeeded:

Chrome attachment succeeded
page title: About:Blank
errors: none

No native-host, app-server, resourcesPath, or browser-control error occurred. A subsequent attachment-only validation also successfully claimed an existing normal https://claude.ai/chat/... Chrome tab and confirmed the exact expected session without typing or sending anything.

So the repaired chain was verified end-to-end:

Codex -> current Chrome plugin -> native host -> current Codex app-server -> Chrome tab control

Product implications

This reproduction supports the lifecycle/self-healing concerns already described in this issue, and adds two points:

1. Recovery UX can route users into the wrong Windows package. OpenAI.ChatGPT-Desktop / ChatGPT Classic is a separate package and does not replace the missing OpenAI.Codex app-server resources. A user following a generic ChatGPT reinstall path can therefore remain broken while believing the desktop app was reinstalled successfully. The recovery flow should identify/verify the required package identity when Codex browser integration is being repaired.
2. Manifest reconciliation should remove or definitively ignore stale app-server entries. In this case Codex recovered successfully by adding a new valid entry, but retained the dangling old entry with the same protocol versions. The host evidently selected the usable/current entry in the successful test, but leaving protocol-compatible dead entries creates unnecessary ambiguity and future regression risk.

No manual registry edits, resourcesPath edits, junction edits, or hand-built native-host configuration were used to obtain the successful recovery.