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

Environment

Windows: 10.0.26200.8457
Microsoft Edge: 150.0.4078.48
Codex AppX: 26.707.8168.0
Codex CLI: 0.144.0-alpha.4
Chrome plugin before update: 26.623.81905
Chrome plugin reported after update: 26.707.61608
Browser: Microsoft Edge with the Codex Chrome Extension installed and enabled

Summary

When Codex updates while the Codex Chrome Extension is enabled in Edge, Edge keeps launching the plugin's extension-host.exe. The process holds files inside the versioned plugin cache. The update can then leave a partially copied plugin directory while Codex reports the new version as installed and enabled. The plugin UI may also be unable to uninstall the plugin.

In this reproduction, four pieces of state diverged:

Installed-plugin state reported 26.707.61608.
The native messaging manifest still launched 26.623.81905.
The latest junction still targeted 26.623.81905.
chrome-native-hosts-v2.json still referenced a removed AppX resources directory from 26.707.3748.0, while the installed AppX was 26.707.8168.0.

Reproduction and evidence

Keep Microsoft Edge running with the Codex Chrome Extension enabled.
Update Codex while Edge continues to launch extension-host.exe from the old versioned plugin cache.
After the update:
- Codex reports the new plugin as installed and enabled.
- The cache can be incomplete. A clean source contained 375 files, but the newly installed cache contained only 342 files and was missing both docs/ and .codex-plugin/plugin.json.
- The native messaging manifest still points to the old versioned extension-host.exe.
- The plugin UI cannot reliably uninstall the plugin.
Browser communication becomes partially functional:
- Codex could enumerate 273 open Edge tabs.
- Claiming/controlling a specific HTTPS tab timed out.
After a CLI remove/add cycle, the cache was again incomplete because the extension host was relaunched during installation.
The extension then showed:

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

chrome-native-hosts-v2.json did contain a resourcesPath, but it pointed to an AppX directory that no longer existed:

...OpenAI.Codex_26.707.3748.0...\app\resources

The currently installed package was:

OpenAI.Codex_26.707.8168.0

Expected behavior

Codex should stop or detach the running native host before replacing plugin files.
A plugin version should become active only after its complete cache has been staged and validated.
Installed-plugin state, latest, the native messaging manifest, and chrome-native-hosts-v2.json should be updated as one recoverable transaction.
On startup, Codex should detect a missing or stale resourcesPath and regenerate the app-server/native-host entry automatically.
Uninstall should work even if the native host is running: stop the owned process, remove state, and report an actionable error if cleanup fails.

Suggested improvements

Stage into a temporary version directory, validate required files, then atomically rename/switch latest.
Before update/remove, identify and stop only the extension-host processes owned by that plugin cache.
Repoint the native messaging manifest to a stable latest path before deleting an old version.
Refresh the AppX resourcesPath after every desktop update and validate that it exists.
Add startup self-healing for mismatched plugin version, host version, junction target, and app-server manifest.
Add a UI repair action that performs the supported stop/reinstall/re-register workflow and preserves a rollback copy.

Comparison

On the same machine, the user's comparable Claude browser integration has not exhibited this update-time lock, partial-install, or stale-manifest failure. This suggests Codex could improve lifecycle coordination and atomicity rather than requiring users to disable the Edge extension before every desktop update.

Temporary recovery used for diagnosis

Back up plugin/config/native-host state.
Disable or stop the running extension host.
Restore a complete plugin cache from the bundled source.
Reinstall the plugin through Codex's plugin command.
Rebuild stale app-server/native-host registration on the next Codex startup.

The workaround is fragile; the product should self-heal without manual cache or manifest intervention.

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

Chrome extension reports app not installed because native-host manifest points to stale plugin link on macOS #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

Temporarily disable the Codex extension in Edge.
Stop the plugin-owned extension-host.exe.
Stop only Codex browser diagnostic Node children that loaded modules from the Chrome plugin cache.
Run codex plugin remove chrome@openai-bundled.
Fully restart Codex.
Reinstall the Chrome plugin from Codex.
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:

extension native host;
browser-client diagnostic Node workers;
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

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.
The latest junction still points to the missing directory 26.707.62119.
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json also points to the missing 26.707.62119\...\extension-host.exe.
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.
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:

Chrome/extension-host.exe or diagnostic Node workers holding plugin-cache files; and
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

ChatGPT Chrome sidebar failed with:
Unable to start ChatGPT
Codex app-server manifest entry is missing required path resourcesPath
The native messaging manifest existed and pointed to a real extension-host.exe.
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
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
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
The official ChatGPT Chrome extension was then completely removed and reinstalled.
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.
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.
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

Codex browser control could enumerate/see Chrome state but could not safely attach to the target tab.
The Chrome extension was installed/enabled. The native-host manifest existed, while native-host registration/provisioning was initially inconsistent during troubleshooting.
Browser plugin uninstall initially returned the generic Failed to uninstall plugin result. A later reinstall reported success, but browser control still failed.
Windows app Repair was attempted. AppX deployment logs later showed both repair attempts had actually failed with 0x80073D02 because OpenAI.Codex was still running.
OpenAI.Codex_26.814.5517.0 was then successfully removed.
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.
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.
8. 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:

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.
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.

I hit this exact error on Windows:

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

Before trying the more involved reinstall/manifest recovery steps, I found a much simpler workaround:

Open the Codex desktop app and tell Codex to connect to Chrome.

Doing that once appears to initialise/regenerate whatever browser integration state was missing. Immediately afterwards, the ChatGPT Chrome extension/sidebar started working normally.

I didn't need to reinstall the extension, manually edit any manifests, or remove/re-add the browser integration.

It might be worth adding this as the first troubleshooting step, since it appears that explicitly asking Codex to connect to Chrome can self-heal this particular state.

Additional current-version reproduction: AppX `26.825.4187.0`, Chrome and Edge

I reproduced the same update-time state divergence on a newer Codex Windows build. This affected both the official Chrome and Edge side panels and also produced the exact nodePath error reported in #35705.

I previously reported the missing latest alias and the native-host diagnostic false green in #30265, with a second current-build reproduction here. That case was observed while using a WSL-native workspace. The reproduction below occurred in a native Windows project context and adds a partially materialized current cache, stale schema-v2 entries, and a missing Edge origin, so the lifecycle failure appears broader than the original WSL path-normalization case.

Sanitized environment

Windows 11 Pro for Workstations 10.0.26200 x64
Codex AppX: 26.825.4187.0
Codex CLI: 0.150.0-alpha.12.2
Bundled Chrome plugin: 26.825.32147
Google Chrome: 152.0.7977.64
Microsoft Edge: 151.0.4129.107
Chrome extension: 1.2.27268.51612
Edge extension: 1.2.30001.51613

User-specific paths, PIDs, tokens, account identifiers, and browser-profile data are omitted.

User-visible failure sequence

The Edge side panel initially showed:

Native transport disconnected

After repairing only the native-host executable/registration layer, the two browsers exposed the next layer of the same failure:

No compatible Codex app-server entry was found

and:

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

State observed before the full diagnostic repair

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json pointed at a missing chrome\latest\...\extension-host.exe target.
Its allowed_origins contained the Chrome extension ID but omitted the installed Edge extension ID.
The current versioned cache at %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.825.32147 was only partially materialized: it contained .codex-plugin and skills, but was missing the runtime extension-host and scripts content.
Both schema-v2 state files contained 20 stale entries and no usable current entry:
- %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
- %USERPROFILE%\.codex\chrome-native-hosts-v2.json
The newest stale entry was from App/plugin generation 26.715.72359; its presence PID was dead and its versioned Node/runtime paths had already been removed.
The current AppX resources and current bundled Node runtime did exist, so this was not simply a missing desktop app or missing Node installation.

Reversible diagnostic repair and verification

The user-owned state was backed up before repair. The diagnostic repair then:

Materialized the complete bundled 26.825.32147 plugin into the immutable versioned cache.
Recreated chrome\latest as a junction to that complete current version.
Synchronized the current signed app-server binaries into the user-owned plugin app-server directory.
Regenerated the native messaging manifest with both installed browser origins.
Wrote a current schema-v2 app-server entry, including existing nodePath, nodeReplPath, resourcesPath, browser client/service paths, and current protocol versions, to both state-file locations.
Stopped only the extension-host processes owned by this plugin cache so each browser could launch a fresh host.

Post-repair process-tree verification showed:

one fresh extension-host.exe per browser;
the Chrome host successfully spawning the current codex.exe app-server --analytics-default-enabled child;
all required current-entry paths resolving to existing files; and
both schema-v2 state files containing the same current entry.

This low-level green loop was not possible before the cache, latest, native manifest, app-server binaries, and schema-v2 state were reconciled together.

Product implication

This confirms that the lifecycle/state-divergence class described here still reproduces on the 26.825 generation. Repairing only the browser extension or only the native messaging manifest is insufficient because it can merely expose the next stale layer.

The updater/startup repair path should treat these as one recoverable transaction:

fully stage and validate the immutable plugin cache before activation;
atomically switch latest;
regenerate Native Messaging registration for every supported installed browser origin;
refresh both schema-v2 state files with current, existing runtime/AppX paths;
prune or definitively ignore stale protocol-compatible entries; and
self-heal when the current AppX/plugin generation does not have a usable ledger entry.

Concrete fix proposal: one committed browser-host generation, with atomic uninstall and startup reconciliation

The current reproduction now has a stable red-to-green boundary, so this can be reduced to an implementation contract rather than another generic reinstall report.

Root cause boundary established by the reproduction

The browser extension itself was present in both Chrome and Edge, and the current AppX resources plus bundled Node runtime existed. The broken state instead spanned four independently updated surfaces:

a partially materialized versioned plugin cache;
a missing/stale latest activation pointer and Native Messaging manifest;
missing browser origins; and
stale schema-v2 app-server entries whose PIDs and runtime paths were no longer usable.

Reconciling all four surfaces together immediately produced a fresh native host for each browser and a current codex.exe app-server child. Repairing only one surface merely exposed the next error. This supports a lifecycle transaction failure rather than a browser-store, system-Node, or antivirus root cause.

Public source already shows two concrete cache-lifecycle gaps

On current openai/codex main:

PluginStore::is_installed is equivalent to “a syntactically valid version directory exists.” It does not establish that the active bundle is complete or runnable. A partially deleted Chrome bundle can therefore remain false-green.
PluginStore::uninstall calls remove_existing_target, which directly calls remove_dir_all. On Windows, a locked executable/native module can make that operation fail after some children have already been removed, leaving the cache mutated but still discoverable as installed.
Install itself already uses a good staged/rename pattern in replace_plugin_root_atomically. The missing piece is extending the same commit semantics to uninstall and to the desktop browser-host activation state.

The browser-specific latest junction, Native Messaging manifest, browser origins, and chrome-native-hosts-v2.json reconciliation do not appear in the public repository, so the complete fix needs a small public PluginStore hardening plus a desktop/browser-host change.

Proposed patch split

1. Make local uninstall logically atomic in `PluginStore`

Replace direct recursive deletion of the active plugin root with a same-parent tombstone transition:

Resolve the exact plugin root.
Rename it to a unique, non-discoverable sibling such as .plugin-remove-<uuid>.
If the rename fails, return an error without mutating the active installation.
Once the rename succeeds, treat uninstall as committed and persist the disabled/uninstalled config state.
Delete the tombstone best-effort after runtime shutdown and retry orphaned tombstones on startup.

This gives only two observable states: the previous complete plugin remains active, or it is atomically absent. It removes the current third state where remove_dir_all has deleted only part of the active bundle.

2. Separate `Installed` from `Ready`

Do not let the presence of a version directory alone drive the Settings UI. Add an installation validation result such as:

Missing | Ready(version) | NeedsRepair(version, reason)

Generic validation should at least require a readable/valid selected manifest. The bundled browser plugin should also have a package-owned readiness validator for its runtime contract, including:

.codex-plugin/plugin.json;
extension-host/windows/<arch>/extension-host.exe and its config;
scripts/browser-client.mjs and scripts/browser-service.mjs;
current app-server binaries;
current nodePath, nodeReplPath, and resourcesPath; and
a Native Messaging manifest whose target exists and whose allowed_origins includes every enabled supported browser.

Settings should show Manage/Installed only for Ready; NeedsRepair should expose a single supported Repair action.

3. Reconcile one immutable browser-host generation

Create one canonical BrowserHostGeneration descriptor containing the AppX version, bundled plugin version, protocol versions, host path, Node paths, app-server path, resources path, and browser origins. Treat the existing junction, Native Messaging manifest/registry entry, and schema-v2 files as derived state from that descriptor.

The update/startup flow should be idempotent:

Acquire a browser-host reconciliation mutex.
Ask owned extension-host, browser-service Node workers, and app-server children to exit; after a bounded timeout, terminate only processes whose executable/command path belongs to the old Codex plugin generation.
Copy the bundled plugin into a same-volume staging directory.
Validate the complete browser-specific readiness contract before activation.
Write the new generation descriptor with temp-file + flush + replace semantics.
Atomically switch latest to the validated version.
Regenerate the Native Messaging manifest/registry entry and merge the official installed Chrome/Edge/Brave/Vivaldi/Opera origins.
Rebuild the schema-v2 app-server state from the same descriptor. Prune, or definitively ignore, entries with a dead presence PID, missing required paths, or an AppX/plugin generation that is no longer installed.
Launch a fresh host and require a version/protocol handshake plus successful app-server spawn before publishing Ready to Settings.

If any step before activation fails, keep the previous known-good generation active. If the app exits between derived-state writes, the next startup should regenerate every derived file from the committed descriptor rather than trusting whichever file was written last.

4. Add a real Repair action

The Repair action should run the same reconciliation state machine, not a separate collection of ad-hoc fixes. It should preserve the previous generation until the new handshake passes and report a typed failing phase such as:

quiesce_locked_process
stage_copy
validate_payload
activate_latest
write_native_manifest
write_app_server_state
handshake

This would also eliminate the current diagnostic false-green where plugin installation succeeds but Native Messaging/app-server reconciliation never completed.

Regression tests / acceptance criteria

The Windows integration suite should cover the exact failure class:

Update while Chrome and Edge both have a live extension-host.exe.
Hold an old plugin executable/native module open and uninstall; assert either a no-op failure or an atomic tombstone transition, never a partial active tree.
Start with only .codex-plugin/ and skills/ in the current version directory; assert NeedsRepair, not Installed.
Start with a missing latest, a manifest targeting a deleted version, and 20 protocol-compatible but unusable schema-v2 entries; assert one startup reconciliation produces one usable current generation.
Omit the Edge origin while both extensions are installed; assert reconciliation merges both origins.
Inject a crash/failure after every transaction phase and restart; assert either the previous generation remains usable or the new generation self-heals completely.
Run Repair twice; the second run must be a no-op with the same descriptor and paths.
End-to-end assert: browser native-message handshake -> current compatible entry selection -> current codex.exe app-server spawn.

Acceptance should be strict:

no manual registry, junction, JSON, or PowerShell repair;
no antivirus exclusion required;
no unrelated process termination;
no Settings Installed/Manage state before the end-to-end handshake; and
a failed update never destroys the last known-good generation.

This is intentionally scoped to the observed lifecycle boundary. It does not require redesigning browser control or app-server protocols; it makes the existing generation changes transactional and self-healing.

Recurrence on the very next Desktop update: AppX `26.825.5331.0` / bundled Chrome plugin `26.825.41651`

This reproduced again on 2026-08-29, immediately after the previous AppX 26.825.4187.0 / plugin 26.825.32147 state had been fully reconciled and verified green. This recurrence is therefore not leftover corruption from the earlier repair.

Red state after the update

Chrome showed the same user-visible failure: Codex app-server manifest entry is missing required path nodePath.
The installed Desktop AppX was 26.825.5331.0, and its bundled Chrome plugin was 26.825.41651, but chrome/latest and the registered browser-host generation were still on 26.825.32147.
Both schema-v2 ledgers contained the same 21 entries. The newest entry still referenced:
- the removed prior Node runtime (...\runtimes\cua_node\e4d75eceaa042f20\bin\node.exe), and
- the removed prior AppX resources directory (OpenAI.Codex_26.825.4187.0_...\app\resources).
0/21 entries had both a usable nodePath and a usable resourcesPath.

Reconcile performed

The same reversible repair described above was run against the currently installed package:

Resolve the current AppX resources, current bundled plugin, current CLI, and current Node runtime.
Materialize and validate plugin 26.825.41651 in an immutable cache directory, then switch chrome/latest to that generation.
Refresh the signed plugin app-server plus native-host manifest/origins.
Prune the stale matching entries and write one current schema-v2 entry to both ledgers.
Start a fresh current extension host, which spawned current codex.exe app-server children.

Green evidence

Health check: Healthy: true, exit code 0.
Both ledgers now contain exactly one entry, are byte-identical, and report plugin generation 26.825.41651.
All critical paths exist: nodePath, nodeReplPath, resourcesPath, codexCliPath, extensionHostPath, browserClientPath, and browserServicePath.
The live extension host is from the current chrome/latest target and has live app-server child processes.
An immediate repeated maintenance run is a no-op: it creates no additional backup and does not restart healthy processes.

Assessment

The local reconcile is a reliable, idempotent workaround for this stale-generation failure class, but it is not a permanent product fix: the next Desktop update can still leave the derived browser-host state pointing at paths removed by the update.

The fix proposal in the preceding comment still fits this new reproduction: commit one BrowserHostGeneration transaction across the immutable plugin directory, latest, signed app-server, native manifest/origins, and both schema-v2 ledgers; distinguish Installed from Ready; validate readiness before commit; and reconcile/prune stale state at startup.

A focused regression test would be:

Start from a healthy generation N with a live browser host.
Update Desktop/AppX to generation N+1 while N's package/runtime paths are removed.
Assert startup reconciliation leaves exactly one usable current entry in both ledgers and the browser handshake succeeds.
Run reconciliation a second time and assert it is a no-op.

This is also the same exact nodePath error reported in #35705.

Counter-observation: the `26.825.5331.0` / `26.825.41651` update reconciled cleanly on this machine

Following up on my earlier reproduction in this thread and on the recurrence reported for this same generation. On this workstation the update to AppX 26.825.5331.0 / bundled Chrome plugin 26.825.41651 self-reconciled with no manual repair. I am reporting it because it appears to bound the trigger: the update transaction can complete correctly, so the failure is not deterministic for this generation.

Sanitized environment

Windows 10 Pro 22H2 10.0.19045.6456 x64
Codex AppX: 26.825.4187.0 -> 26.825.5331.0
Bundled Chrome plugin: 26.825.32147 -> 26.825.41651
Codex CLI (ledger cliVersion): 26.825.41651
Google Chrome: 152.0.7977.65
Chrome extension: 1.2.27268.51612
Edge is installed but the ChatGPT extension is not, so the Edge path was not exercised here

User-specific paths, PIDs, tokens, and account identifiers are omitted.

Observed post-update state

A read-only check roughly forty minutes before the update showed the prior generation healthy. The update then landed with no intervention and, on its own:

materialized the complete 26.825.41651 plugin into the versioned cache;
repointed chrome\latest to that version;
rewrote both schema-v2 ledgers, which remained byte-identical; and
added a current entry whose nodePath, nodeReplPath, resourcesPath, codexCliPath, extensionHostPath, browserClientPath, and browserServicePath all resolve to existing files.

The Native Messaging manifest needed no rewrite, because it targets the junction rather than a pinned version:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

Read-only live verification. extension-host.exe was launched by Chrome itself over native messaging:

cmd /d /s /c ""...\chrome\latest\extension-host\windows\x64\extension-host.exe" chrome-extension://<id>/ --parent-window=0"
  < \\.\pipe\chrome.nativeMessaging.in.<handle>
  > \\.\pipe\chrome.nativeMessaging.out.<handle>

and it spawned a current app-server child on first side-panel use:

...\.codex\plugins\.plugin-appserver\codex.exe app-server --analytics-default-enabled

Two residual defects that survived the clean update

1. Dangling entries persist across generations, though not indefinitely.

The ledger now holds one valid entry and four dangling ones:

26.818.31338   dangling  (nodePath, nodeReplPath, resourcesPath missing)
26.818.32112   dangling  (nodePath, nodeReplPath, resourcesPath missing)
26.818.61809   dangling  (nodePath, nodeReplPath, resourcesPath missing)
26.825.32147   dangling  (nodePath, nodeReplPath, resourcesPath missing)
26.825.41651   VALID     (7/7 required paths resolve)

Every dangling entry fails on exactly the same three keys: the removed Node runtime and the removed AppX resources directory. The legacy v1 ledger is also still present.

The 26.814.41957 entry named in my earlier comment is no longer there, so entries do get dropped at some point. I did not determine the mechanism or the retention window, and I did not prune anything manually. What is reproducible is narrower and still a defect: a fully successful reconcile adds a valid entry without pruning the generation it directly replaces. 26.825.32147 was the serving entry earlier the same day and is now dangling alongside three older ones. Four generations' worth accumulate this way, which is presumably how the 20+ entry ledgers reported elsewhere in this thread are reached.

2. presence on the current entry goes stale within the same session.

The valid 26.825.41651 entry records a presence.pid, startedAt, and lastSeenAt from the reconcile at update time. Roughly three hours later the live app-server child was running under a different PID and the entry had not been updated. presence therefore reflects the process that existed when the entry was written, not the process currently serving the browser.

This matters for the pruning proposals in this thread: if reconciliation uses dead-PID detection to decide what to discard, presence is not maintained for live entries either, so a live generation can look as dead as a genuinely orphaned one.

A read-only pass/fail test for other users

Several reports here infer success or failure from the UI. That is not sufficient. The extension renders its side panel and loads prior conversations over the network with no native host involved, so a broken native path can look identical to a working one. I nearly drew the wrong conclusion this way.

The cheap discriminator is the process tree:

extension-host.exe
  parent = cmd.exe carrying \\.\pipe\chrome.nativeMessaging.in.<handle>
           and the chrome-extension://<id>/ origin    -> the browser did launch the host
  child  = codex.exe app-server                       -> the host did reach the app-server

If the host has no app-server child, the panel is talking to the service and nothing else.

Separately, extension-host-config.json is absent on this machine and the host runs correctly regardless, so its absence is not on its own diagnostic.

No registry edits, resourcesPath edits, junction edits, or hand-built native-host configuration were used. The state above is what the updater produced unaided.

October 3 follow-up: browser-integration guardian intervened after two current-build updates

Following up on my August reproductions and fix proposal in this issue. We have kept a local scheduled guardian that checks the current Windows browser integration and reconciles mismatched state. The integration is healthy after its repairs, but that post-repair result should not be interpreted as evidence that the official update path has been fixed.

Two repair events today

Windows 11 Pro for Workstations, x64. All events below occurred on 2026-10-03. Local time is MYT (UTC+08:00).

Desktop/AppX	Bundled Chrome plugin	Guardian detected mismatches (UTC / MYT)	Guardian reported successful repair (UTC / MYT)
`26.930.3748.0`	`26.930.31428`	02:47:45.548 / 10:47:45.548	02:47:59.410 / 10:47:59.410
`26.930.3930.0`	`26.930.31730`	05:22:45.691 / 13:22:45.691	05:23:00.372 / 13:23:00.372

Both events logged the same conditions before repair:

Plugin cache latest does not target version <current bundled Chrome plugin>.
Native-host config is missing or has a stale nodePath.
Native-host config is missing or has a stale nodeReplPath.
App-server ledger has no unique current entry at both %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json and %USERPROFILE%\.codex\chrome-native-hosts-v2.json.

The guardian reported successful repair for each corresponding package/plugin pair. A fresh read-only CheckOnly after the latest repair reports Healthy: true, no issues, current package 26.930.3930.0, current plugin 26.930.31730, and chrome/latest targeting that current plugin.

What this does and does not establish

This is direct evidence that our guardian detected configuration mismatches against its expected current generation and then reconciled them on these two current builds. The guardian's health check validates the current generation's paths and configuration; it is not an end-to-end browser handshake test.

The log messages are the guardian's own diagnostic predicates: “missing or stale” does not distinguish absence from an old path, and “no unique current entry” means that the number matching all of our expected version/path fields is not exactly one, rather than establishing that every existing ledger entry is unusable. We did not capture a raw pre-repair ledger snapshot or a browser-side error/handshake for these two events, and did not disable the guardian to determine whether the official app would eventually self-reconcile. Our check also requires a specific current-generation configuration, which may be stricter than the product's minimum working requirements; it selects the most recently modified complete Node runtime directory, which need not prove the runtime the official app intended to use.

Accordingly, we can confirm that today's healthy state follows our local repair; we cannot use that healthy state to certify an upstream fix, nor claim these observations prove the extension fails on every update or on every machine.

Request for the maintainers

Could you confirm whether a fix for the Windows update/startup browser-host reconciliation described in this issue and #35705 has shipped? If so, please identify the desktop build and expected activation/self-reconciliation behavior, including any delay.

A useful acceptance check for the product fix remains: update a working generation N to N+1 with an existing browser host, allow N's versioned paths to be removed, and verify without a third-party guardian that the selected native host and app-server entry resolve to usable current runtime/resources and complete a browser handshake. Repeat startup/reconciliation to check that healthy state remains stable.

Until that is verified on this workstation, we are retaining the guardian workaround. The earlier transaction/reconciliation proposal in this thread remains relevant to the observed generation drift.

Concrete solution: local implementation and proposed product repair

The solution is to reconcile the browser integration as one owned generation when the desktop updates or starts, rather than treating plugin-directory presence as readiness. Below is the local repair we actually use, followed by the stronger transaction contract proposed for the official implementation.

Implemented local guardian workaround

The existing guardian runs at logon and every five minutes, takes a maintenance mutex, and returns without changing files or restarting processes when its configuration checks pass. It defers repair until the desktop's current runtime is available. Its repair script:

Reads the installed AppX package and bundled Chrome plugin metadata; validates required source files and the native host's Authenticode signature.
Confirms exit of native-host processes whose executable paths are verified inside the owned Chrome plugin cache.
Copies the complete bundled plugin into the versioned cache, verifies the host and required browser client/service files, then reconciles chrome/latest to that version.
Locates the current desktop CLI runtime. Confirms exit of app-server processes inside the separately owned plugins/.plugin-appserver root, stages the managed binaries from that runtime, backs up/replaces the old runtime directory, and compares source/destination SHA-256 hashes.
Resolves the complete local computer-use Node runtime, regenerates the host configuration and native-messaging manifest from bundled metadata, and maintains the browser origins/registration. The local runtime-selection heuristic is described in the evidence caveat above; the official implementation should use its authoritative runtime identity.
Backs up each schema-v2 ledger and writes a current entry to both locations, preserving valid entries outside the repair's matching channel/extension/native-host scope. An invalid or unrecognized ledger is backed up and rebuilt. The entry contains existing Node, resources, app-server, extension-host and browser client/service paths.
Reruns the same configuration checks and records the before/after state. A subsequent healthy guardian run is a no-op.

The local code atomically replaces individual JSON files and stages the app-server directory with a restoration path for a failed directory move. Cache copying is in place and the junction switch uses separate delete/create operations. The runtime restoration catch covers a failed directory move; later hash/config/registry/ledger failures do not automatically roll back earlier changes. It is not a single crash-atomic transaction across cache, junction, manifest and both ledgers, and its configuration check is not a browser handshake. It is an implemented workaround, not the complete product architecture proposed below.

Process-exit improvement already implemented and tested

The previous helper requested termination and then polled path-filtered process discovery. A previously verified process could disappear from that discovery while its original process had not finished exiting. The helper now retains original process handles and confirms exit before the protected file replacement proceeds.

The implemented sequence is:

discover processes with executable paths inside the owned runtime root
for each discovered process:
    obtain the Process object and retain its kernel handle
    if already exited: continue
    revalidate its executable path is still inside that root
    otherwise abort

start one shared 30-second termination/exit budget
request the existing scoped termination on those verified Process objects
wait for each original process to exit using the remaining shared budget
if a wait times out: abort this replacement step
rescan the owned root
if a replacement process has appeared: abort, do not terminate that new process
dispose retained handles in finally
only then continue replacing files in that root

The main desktop app and Chrome are outside the helper's selected roots; this change does not add termination targets. It is not a general system-wide process or SQLite repair.

Validation already completed for this local change:

An isolated mocked regression reproduced the original helper incorrectly allowing replacement when a verified process had not exited and path-based discovery no longer exposed it.
Five cases using the helper extracted from the script's AST, with mocked discovery/termination, passed under Windows PowerShell 5.1 and PowerShell 7: delayed exit/path disappearance, timeout, a newly spawned replacement, an already-exited race, and a changed path/identity.
An isolated real Windows executable was stopped through the helper, with original-handle exit confirmation and disposal; existing desktop process IDs remained present.
The deployed repair script matches the tested source's SHA-256, and a fresh read-only configuration check passes.

These checks validate the helper and local deployment. They do not establish the cause of either historical desktop startup incident or a full browser handshake for today's two repair events.

Proposed official update/startup reconciliation

Use a canonical browser-host generation containing the desktop package, plugin, authoritative Node and CLI runtime identities, protocol versions, required paths and supported extension origins. Derive activation pointers, manifests and resolver entries from that one generation.

reconcile(desired_generation):
    serialize activation for this browser-host owner
    if a compatible committed generation is Ready:
        return without replacing files or restarting processes

    stage desired plugin/runtime generation
    validate bundle completeness, signatures/hashes and required paths
    confirm exit of only the verified owned processes that block replacement
    if timeout or a replacement process appears:
        leave the staged generation unactivated and report a retryable state

    prepare manifests and resolver entries for desired_generation
    publish a recoverable activation transaction with a generation commit record
    make readers select a fully committed compatible generation
    complete a fresh native-host -> app-server -> browser handshake
    record Ready only after the handshake succeeds

on startup or interrupted activation:
    resume or reconcile the same generation idempotently
    do not report Ready merely because a version directory exists

Implementation requirements:

A generation commit record/activation journal should let startup resume interrupted multi-file writes. Several sequential atomic JSON writes do not form one atomic transaction.
Publish one unambiguous selected compatible entry for this browser-host owner, while preserving other channels, installations and unrelated integrations. Multiple ledger entries are not inherently a failure.
Reject or ignore entries with missing required paths or incompatible protocols. A dead recorded presence.pid alone is insufficient evidence that a generation is unusable; it can be stale while a replacement child is serving.
If the selected generation is incomplete, return an explicit recoverable initialization state and reconcile it; do not let an incomplete cache produce a false “installed/ready” result.
Use the product's own runtime manifest/identity, not a latest-modified-directory guess, for Node and CLI selection.
If a cached executable is locked during uninstall, avoid partially deleting an active bundle. Detach/tombstone the owned generation after activation/exit gates and defer cleanup of a locked tombstone.
Preserve unrelated configuration and browser registrations. Ordinary repair should not depend on clearing the user's SQLite state, installing system Node or weakening antivirus protection.

Product regression checks

Start with generation N and a live native host; update to N+1 as N's package/runtime paths disappear. Without the guardian, require a complete current bundle, a resolvable compatible selected entry and a successful Chrome/Edge native handshake.
Exercise incomplete cache, a dangling latest target, missing resolver fields, incompatible protocols and multiple compatible entries. Check deterministic selection/reconciliation rather than exact-one-entry assumptions.
Hold an owned executable open; simulate delayed teardown/path disappearance, timeout and host respawn. Activation must respect the confirmed-exit boundary and avoid killing unrelated processes.
Interrupt activation after each staged write and before/after commit publication. Startup must recover to a coherent generation; JSON parse success alone is insufficient.
Repeat reconciliation after successful activation. Require no unnecessary file replacement or process restart.

This supplies the concrete repair sequence and the tested process-lifecycle improvement behind our workaround. The official generation transaction and handshake are proposed implementation work; no upstream source patch or PR has been submitted as part of this comment.

October 12 recurrence: stale resourcesPath after a newer Windows desktop update

Additional evidence for the stale AppX resourcesPath portion of this issue, on Google Chrome. A previous local repair was performed on October 7; the user reported the integration failing again on October 12.

Environment:

Installed OpenAI.Codex AppX: 26.1007.2314.0, x64 (queried with Get-AppxPackage; not the About dialog).
Windows version from System.Environment.OSVersion: 10.0.26200.0.
Chrome: 155.0.8059.39.
ChatGPT Chrome extension: 1.26.901.11451.
Native host: com.openai.codexextension.

Observed before this repair:

HKCU Native Messaging registration and its JSON manifest existed. The registered extension-host.exe resolved through chrome/latest and existed.
%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json had schemaVersion 2 and one runtime entry. Its recorded appVersion was still 26.917.71314 and updatedAt was 2026-09-29T08:30:47.334Z.
That entry's resourcesPath was:

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

Test-Path returned false. The currently installed package's resources directory existed at:

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

The other checked required paths existed: browserClientPath, browserServicePath, codexCliPath, codexHome, extensionHostPath, nodePath and nodeReplPath. The configured nodeModuleDirs target also existed.
A direct Native Messaging codexRuntime/hello request succeeded before repair. A successful basic host handshake therefore did not establish that the registered resourcesPath was usable.

Reversible diagnostic repair:

Saved the original manifest bytes as a backup.
Replaced only the missing resourcesPath with the verified installed AppX resources directory. Protocol fields, origins and the other runtime paths were preserved.
Validated every required path after saving.
A newly launched Native Messaging host then returned successful codexRuntime/hello and codexRuntime/ensure responses. ensure selected the repaired entry.

Scope of the evidence: agent-side Chrome discovery and navigation to a public documentation page also worked before this repair. The exact user-facing side-panel error was not captured, and the user has not yet confirmed the original UI symptom is resolved. This report establishes a recurring stale registration and successful post-repair runtime initialization; it does not establish that every browser feature was failing, or reproduce the file-lock/partial-cache portions of this issue.

Please reconcile version-specific AppX resources paths on desktop update/startup, validate the selected entry's required paths, and expose a supported repair action. A regression check should update a working installation from N to N+1, remove N's package directory, and verify actual native-host/app-server initialization with no manual JSON repair. A local repair should not have to be repeated after another app update.

User-specific paths, account identifiers, tokens, runtime URLs, session IDs, browser-tab data and raw logs are omitted.

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

Description

Environment

Summary

Reproduction and evidence

Expected behavior

Suggested improvements

Comparison

Temporary recovery used for diagnosis

Activity

github-actions commented on Jul 13, 2026

isCopyman commented on Jul 13, 2026

Resolution update: clean uninstall/reinstall restored the integration

Additional lock source found during uninstall

Recovery sequence that worked

Post-reinstall verification

Product implication

buchicao-star commented on Jul 17, 2026

Additional reproduction on Google Chrome and a newer Windows build

Sanitized environment

Observed state

Expected behavior

FeyZha commented on Jul 18, 2026

Barry-886 commented on Aug 1, 2026

PRM333 commented on Aug 4, 2026

Additional reproduction: AppX physically installed on a secondary encrypted drive

zemeng5208 commented on Aug 12, 2026

dallall123 commented on Aug 20, 2026

ryandaly49 commented on Aug 20, 2026

Environment

Failure sequence observed

Impact

Additional observation

dallall123 commented on Aug 20, 2026

ryandaly49 commented on Aug 20, 2026

What was happening when it froze

Verified impact of this freeze

Why this matters for usage / credits

darcyolynyk-cpu commented on Aug 20, 2026

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

Failure sequence

Correct-package recovery

Live post-recovery validation

Product implications

evilrix commented on Aug 28, 2026

medking82 commented on Aug 28, 2026

Additional current-version reproduction: AppX 26.825.4187.0, Chrome and Edge

Sanitized environment

User-visible failure sequence

State observed before the full diagnostic repair

Reversible diagnostic repair and verification

Product implication

medking82 commented on Aug 28, 2026

Concrete fix proposal: one committed browser-host generation, with atomic uninstall and startup reconciliation

Root cause boundary established by the reproduction

Public source already shows two concrete cache-lifecycle gaps

Proposed patch split

1. Make local uninstall logically atomic in PluginStore

2. Separate Installed from Ready

3. Reconcile one immutable browser-host generation

4. Add a real Repair action

Regression tests / acceptance criteria

medking82 commented on Aug 29, 2026

Recurrence on the very next Desktop update: AppX 26.825.5331.0 / bundled Chrome plugin 26.825.41651

Red state after the update

Reconcile performed

Green evidence

Assessment

darcyolynyk-cpu commented on Aug 30, 2026

Counter-observation: the 26.825.5331.0 / 26.825.41651 update reconciled cleanly on this machine

Sanitized environment

Observed post-update state

Two residual defects that survived the clean update

A read-only pass/fail test for other users

medking82 commented on Oct 3, 2026

October 3 follow-up: browser-integration guardian intervened after two current-build updates

Two repair events today

What this does and does not establish

Request for the maintainers

Concrete solution: local implementation and proposed product repair

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

Additional current-version reproduction: AppX `26.825.4187.0`, Chrome and Edge

1. Make local uninstall logically atomic in `PluginStore`

2. Separate `Installed` from `Ready`

Recurrence on the very next Desktop update: AppX `26.825.5331.0` / bundled Chrome plugin `26.825.41651`

Counter-observation: the `26.825.5331.0` / `26.825.41651` update reconciled cleanly on this machine