Windows Codex Desktop corrupts chrome@openai-bundled cache on startup when Chrome native host locks extension-host.exe

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

• #21670

Powered by Codex Action

I ran into a very similar issue on Windows: the Chrome extension popup showed Connected, but Codex could no longer expose or use @Chrome after restarting Codex/Chrome.

What helped locally was fully closing both Codex and Chrome, making sure chrome.exe and extension-host.exe were gone, then starting Codex first, waiting for the Chrome/Browser plugins to load, and only then starting Chrome.

I wrote up the steps here in case it helps others:
https://treasure-lung-30f.notion.site/Codex-Chrome-Extension-on-Windows-Setup-and-Troubleshooting-Guide-36830cb58ab8816eb0a4e8b93153a94c

This is just a user workaround from local debugging, not an official fix.

Additional confirmation from another Windows/WSL install, on newer versions.

Environment

• OS: Windows with WSL Ubuntu enabled for Codex
• Codex Desktop app version observed in process path: 26.519.3891.0
• Bundled Chrome plugin cache version: 26.519.31651
• Chrome extension version: 1.1.5
• Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex config includes:

runCodexInWindowsSubsystemForLinux = true

[plugins."chrome@openai-bundled"]
enabled = true

User-visible symptoms

• Chrome extension UI shows green Connected.
• Typing @ in Codex does not show Chrome as an available mention target.
• Chrome can sometimes be selected only from the plus-menu plugin UI.
• In a new conversation, asking Chrome to list open tabs fails with:

I can't list Chrome's open tabs from this session. The requested chrome plugin is not available as a callable tool here, and it is not listed as an installable plugin. Only Browser and GitHub are available, and Browser does not expose Chrome tab enumeration.

Earlier install/uninstall attempts from Codex also showed:

Failed to install plugin
Failed to uninstall plugin

The uninstall failure was resolved only after stopping stale extension-host.exe processes.

Diagnostics

Chrome-side checks pass:

• Chrome extension is installed and enabled in the Default profile.
• Native messaging host manifest exists at:

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

• Extension install check reports installed/enabled.
• The native host executable exists at:

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

But after restarting Codex, the Chrome plugin cache is again missing key Codex-side files:

%CODEX_HOME%\plugins\cache\openai-bundled\chrome\26.519.31651\.codex-plugin\plugin.json
%CODEX_HOME%\plugins\cache\openai-bundled\chrome\26.519.31651\app-server-runtime\node_repl

The latest pointer was checked/corrected to:

26.519.31651

but Chrome still does not appear in @ and is still not exposed as a callable tool in new conversations.

Separate Chrome extension hotfix test

A Chrome Web Store review suggested that extension background.js calls nonexistent chrome.runtime.getVersion() and should use chrome.runtime.getManifest().version. A temporary local test patch was applied:

chrome.runtime.getVersion ??= () => chrome.runtime.getManifest().version;

That patch persisted after restarting Chrome and Codex, and the extension still checked as installed/enabled. However, Codex still did not expose Chrome as a callable tool. So that appears to be a separate extension-side issue, while the remaining blocker is still the Codex-side plugin registration/cache state described in this issue.

Conclusion

This still reproduces on Codex Desktop 26.519.3891.0, bundled Chrome plugin cache 26.519.31651, and Chrome extension 1.1.5. The important new observation is that Codex restart leaves the Chrome plugin cache missing .codex-plugin/plugin.json and app-server-runtime/node_repl, while the Chrome extension itself remains installed and connected.

Additional confirmation on a newer Windows Desktop build, with one extra impact: this can also make computer-use@openai-bundled disappear from active discovery/runtime.

Environment

• Codex Desktop package path version: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Bundled plugin cache version observed: 26.527.31326
• OS: Windows x64
• Chrome extension/native host ID observed: hehggadaopoacecdllhhajmbjkdcmajg
• Paths below are redacted as %CODEX_HOME%

What changed versus the original report

On this install, chrome@openai-bundled had:

%CODEX_HOME%\plugins\cache\openai-bundled\chrome\latest

as a junction pointing into the temporary bundled marketplace, not a stable versioned cache directory:

%CODEX_HOME%\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome

So when Chrome kept the Codex Chrome extension native host alive, the native host locked the temporary bundled marketplace path itself:

%CODEX_HOME%\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64\extension-host.exe

An exclusive-open test against that file failed with Windows reporting it was being used by another process. There were three lingering extension-host.exe native messaging processes from the Codex Chrome extension.

User-visible symptom

After Codex restart, Computer Use appeared to be installed/enabled in config/cache, but disappeared from active availability:

[plugins."computer-use@openai-bundled"]
enabled = true

and the cache still existed:

%CODEX_HOME%\plugins\cache\openai-bundled\computer-use\26.527.31326

but the active bundled marketplace was incomplete and only contained chrome:

%CODEX_HOME%\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome

At runtime, Computer Use failed with:

Computer Use native pipe path is unavailable

and the request metadata no longer had Computer Use helper metadata available to the session.

Log evidence

Earlier in the same day/session, the bundled marketplace was healthy and Computer Use was available:

[computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32
[BundledPluginsMarketplace] bundled_plugins_runtime_marketplace_written pluginCount=4 pluginNames=["browser","chrome","computer-use","latex"] targetMarketplaceRoot=%CODEX_HOME%\.tmp\bundled-marketplaces\openai-bundled
[BundledPluginsMarketplace] bundled_plugins_marketplace_added marketplaceName=openai-bundled marketplacePluginNames=["browser","chrome","computer-use","latex"] marketplaceRoot=%CODEX_HOME%\.tmp\bundled-marketplaces\openai-bundled

After restart/focus reconcile while the Chrome native host was still alive:

[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
[computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" platform=win32
[BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed errorCode=EBUSY errorMessage="EBUSY: resource busy or locked, rmdir '%CODEX_HOME%\\.tmp\\bundled-marketplaces\\openai-bundled\\plugins\\chrome\\extension-host\\windows\\x64'"

There were also repeated install/reinstall failures in the same class:

errorCategory=plugin_cache_windows_file_lock
errorMessage="failed to install plugin: failed to back up plugin cache entry: Access is denied. (os error 5)"
pluginName=chrome

Workaround confirmed

The user removed/disabled the Chrome Codex extension, killed three lingering extension-host.exe processes in Task Manager, then restarted Codex Desktop. After that, Computer Use became available again.

This suggests the blast radius is larger than just @chrome: a locked chrome native host can leave the shared bundled marketplace incomplete, which then breaks computer-use helper path resolution even though the computer-use cache/config entries still exist.

Suggested fix direction

In addition to avoiding replacement of a running native host cache path, it may be worth ensuring chrome\latest never points into the temporary bundled marketplace root used for regeneration, or making bundled marketplace regeneration atomic so a lock in one plugin cannot leave the whole openai-bundled marketplace with only a partial plugin set.

Additional confirmation on Codex Desktop 26.527.3686.0, with a full Computer Use failure/recovery chain.

This appears to be the same underlying issue as the Chrome native host file lock described here, but the blast radius included computer-use@openai-bundled: the Computer Use native pipe stopped being created because the bundled plugin cache/marketplace entered a partial state after Chrome plugin reconciliation hit Windows file locks.

Environment

• Windows: 10.0.26220
• Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Bundled plugin cache version observed: 26.527.31326
• Runtime mode: Windows native, runCodexInWindowsSubsystemForLinux = false
• Codex home redacted as %CODEX_HOME%
• Logs redacted as %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\06\01\...
• Chrome extension ID involved: hehggadaopoacecdllhhajmbjkdcmajg

Failure sequence observed

Computer Use worked earlier in the same app session:

[computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32

Later, after bundled plugin reconcile/focus events while the Codex Chrome extension native host was alive, Computer Use failed:

[computer-use-native-pipe] computer-use native pipe helper paths changed platform=win32
[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
[computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" platform=win32

The same time window showed Chrome plugin/native host cache lock failures:

bundled_plugins_marketplace_resolve_failed errorCode=EBUSY errorMessage="EBUSY: resource busy or locked, rmdir '%CODEX_HOME%\\.tmp\\bundled-marketplaces\\openai-bundled\\plugins\\chrome\\extension-host\\windows\\x64'"
bundled_plugins_marketplace_install_failed errorCategory=plugin_cache_windows_file_lock errorMessage="failed to uninstall plugin: failed to remove existing plugin cache entry: Access is denied. (os error 5)" pluginName=chrome

Process inspection found lingering native host processes launched from the Chrome extension:

%CODEX_HOME%\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0

At one point the active %CODEX_HOME%\plugins\cache\openai-bundled cache was partial: browser and chrome existed, but computer-use was missing. The regenerated temporary marketplace did contain computer-use, so the issue was not that the bundled marketplace source lacked Computer Use; the active cache/session state was inconsistent.

The Computer Use client then failed before any list_apps() call because the desktop app did not inject a native pipe path:

Computer Use native pipe path is unavailable

The client code path reads the pipe from:

globalThis.nodeRepl?.env?.SKY_CUA_NATIVE_PIPE_DIRECTORY

so once the desktop host fails to start/publish the native pipe, the plugin client cannot recover by itself.

Recovery that worked

The durable local workaround was to remove the Chrome native-host trigger, then rebuild bundled caches while Codex/Chrome were fully stopped:

1. Remove/disable the Codex Chrome extension in Chrome.
2. Disable/remove chrome@openai-bundled in Codex settings/config.
3. Keep these enabled:

```toml
[plugins."computer-use@openai-bundled"]
enabled = true

[plugins."browser@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = false
```

1. Stop Chrome and all lingering extension-host.exe native messaging processes.
2. Stop Codex completely.
3. Backup-rename, rather than delete:

``text
%CODEX_HOME%\.tmp\bundled-marketplaces
%CODEX_HOME%\plugins\cache\openai-bundled
``

1. Restart Codex with Chrome closed.

One important detail: after computer-use was reinstalled into the cache, the already-running Codex process still did not publish the Computer Use pipe. A second Codex restart was required so the desktop host would see the restored helper paths at startup and inject the native pipe path into the session.

Successful final state

After the second restart, logs showed:

[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 status=already-present
[computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32
[BundledPluginsMarketplace] bundled_plugin_chrome_extension_sync_decision chromeExtensionSyncAction=keep_missing ... isExtensionInstalled=false isPluginInstalled=false pluginName=chrome
[BundledPluginsMarketplace] bundled_plugin_install_skipped_missing pluginName=chrome
[BundledPluginsMarketplace] bundled_plugin_install_skipped_current pluginName=computer-use

Files existed again:

%CODEX_HOME%\plugins\cache\openai-bundled\computer-use\26.527.31326\scripts\computer-use-client.mjs
%CODEX_HOME%\plugins\cache\openai-bundled\computer-use\26.527.31326\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

No Chrome or extension-host.exe processes remained. The native pipe and helper process existed, sky.list_apps() returned apps, and a Notepad smoke test succeeded by typing and reading back:

computer use test repaired 2026-06-01T13:41:32.169Z

Suggested product fix

The main issue still seems to be that a running Chrome native host can lock either the active plugin cache or the temporary bundled marketplace path, and a failure in chrome reconciliation can leave the shared openai-bundled state inconsistent enough to break unrelated bundled plugins like computer-use.

Possible fixes:

• Never run extension-host.exe from a cache/tmp path that bundled reconcile may remove or replace.
• Ensure chrome\latest cannot point into %CODEX_HOME%\.tmp\bundled-marketplaces.
• Stage bundled plugin updates into new immutable directories and switch pointers atomically.
• Treat one plugin's file-lock failure as isolated, so chrome cannot remove or hide helper paths for computer-use.
• After computer-use is installed/restored during a running session, re-run native pipe helper path resolution and publish SKY_CUA_NATIVE_PIPE_DIRECTORY without requiring a full app restart.

Related symptoms/issues: #25391 and #25571.

Thanks for the detailed write-up. I maintain a small community Codex Skill focused specifically on Windows Codex Desktop failures around the bundled Chrome and Computer Use plugins:

https://github.com/navi118/codex-desktop-doctor-skill

It is not a general Codex repair script, and it does not make automatic destructive changes. The goal is to help an agent collect the relevant local evidence first, especially around the Codex Chrome Extension/native host, bundled marketplace/cache state, Computer Use helper/native pipe availability, and Windows file-lock / access-denied patterns such as plugin_cache_windows_file_lock, EBUSY, os error 5, missing-helper-path, or Windows Computer Use helper paths are unavailable.

This issue is very close to the failure class the Skill was created for: Chrome native-host/cache lifecycle problems on Windows that can leave the bundled plugin cache or runtime marketplace in a partial state, sometimes with Computer Use affected as collateral damage.

Sharing it here as a cautious diagnostic aid, not as an official fix or a one-size-fits-all workaround.

Root cause (confirmed) and a corruption-free fix for the Windows plugin-cache os error 5 / half-removed cache

I think I've pinned the mechanism behind "failed to remove existing plugin cache entry … (os error 5)" / the half-materialized bundled plugin cache on Windows (this issue, and #21670), and have a small, Windows-scoped fix that I've validated locally.

Where it happens (open-source)

codex-rs/core-plugins/src/store.rs:

• remove_existing_target() (used by PluginStore::uninstall) calls fs::remove_dir_all(path).
• remove_old_plugin_versions() calls fs::remove_dir_all(entry.path()).

std::fs::remove_dir_all deletes entries one-by-one. When a file inside the tree is locked — typically the plugin's own native messaging host (extension-host.exe) running out of …/plugins/cache/openai-bundled/chrome/latest/extension-host/windows/x64/, or any file a plugin holds open without FILE_SHARE_DELETE — the call deletes some siblings and then fails, leaving a half-removed (corrupt) cache entry that is missing .codex-plugin/plugin.json / assets.

Empirical confirmation (Windows 11)

Holding one file in a plugin tree open with FILE_SHARE_READ only (no FILE_SHARE_DELETE, which is what a running native host effectively does), then calling std::fs::remove_dir_all on the tree:

naive remove_dir_all under no-delete-share lock:
  err = Some(32)            // ERROR_SHARING_VIOLATION
  base_exists           = true
  plugin_json_survived  = false   // already deleted before the failure
  assets_survived       = false   // already deleted before the failure

So plugin.json and assets are gone but the directory remains — exactly the "missing plugin.json/assets" corruption reported here. Notably, **renaming the parent directory aside is also rejected under this lock**, so "just move it out of the way" is not sufficient on its own.

Downstream effect observed on a real install (Desktop 26.601.2237.0): while Chrome's extension-host.exe holds the bundled chrome cache dir, a plugin refresh fails to remove/replace it, after which computer-use resolves to reason=missing-helper-path and the Computer Use native pipe never starts (the symptom in #25507 / #25512). Fully closing Chrome and restarting Codex — so nothing locks the cache during the refresh — reliably restores it, consistent with this being a lock-during-removal problem.

Proposed fix (Windows-scoped, no behavior change elsewhere)

Make the removal corruption-free: relocate the tree with an atomic rename first and only delete the relocated copy, so the canonical path is only ever fully present or fully gone — never half-deleted. If even the rename is blocked by the lock, retry briefly and then return the error with the directory left fully intact, so callers keep the previous valid cache instead of a corrupt one.

#[cfg(windows)]
fn remove_dir_all_resilient(path: &Path) -> io::Result<()> {
    let Some(parent) = path.parent() else {
        return fs::remove_dir_all(path);
    };
    let file_name = path.file_name().and_then(|n| n.to_str()).unwrap_or("plugin");
    let nonce = std::time::SystemTime::now()
        .duration_since(std::time::UNIX_EPOCH)
        .map(|e| e.as_nanos()).unwrap_or(0);
    // `~` is not a valid plugin version char, so version discovery ignores this
    // relocated dir if best-effort cleanup can't finish while the lock is held.
    let relocated = parent.join(format!("{file_name}~trash~{nonce}"));

    let mut attempt = 0;
    loop {
        match fs::rename(path, &relocated) {
            Ok(()) => break,
            Err(err) if is_locked_error(&err) && attempt < RELOCATE_LOCK_RETRIES => {
                attempt += 1;
                std::thread::sleep(RELOCATE_LOCK_RETRY_DELAY);
            }
            Err(err) => return Err(err), // leave the dir intact; never partial-delete
        }
    }
    let _ = fs::remove_dir_all(&relocated);
    Ok(())
}

#[cfg(windows)]
fn is_locked_error(err: &io::Error) -> bool {
    // ACCESS_DENIED(5), SHARING_VIOLATION(32), LOCK_VIOLATION(33), DIR_NOT_EMPTY(145)
    matches!(err.raw_os_error(), Some(5 | 32 | 33 | 145))
}

remove_existing_target and remove_old_plugin_versions call this instead of fs::remove_dir_all. On non-Windows it's a thin alias for fs::remove_dir_all (zero behavior change).

Test / validation

I validated the removal logic with a standalone reproduction on Windows 11: with one
file held open FILE_SHARE_READ, std::fs::remove_dir_all deletes siblings and then
fails (err=Some(32), plugin.json/assets already gone) — a corrupt half-removed
tree — while the relocate-first version leaves the tree fully intact and reports the
error; with no lock it removes the tree cleanly. The same behavior is covered by a
#[cfg(windows)] unit test added next to the change in store_tests.rs (installs a
plugin, holds a FILE_SHARE_READ handle on a file inside it, asserts uninstall
errors but the manifest/version survive).

Note: I did not run the full cargo test -p codex-core-plugins locally — the crate's
dependency tree builds several C/asm *-sys crates (aws-lc-sys, ring, zstd-sys, …)
that need a full C toolchain I don't have on this machine — so CI is the right place to
exercise the added test.

Offer

I have the change + test ready against main. docs/contributing.md says PRs must be invited — would the team welcome a PR for this? If so I'll sign the CLA and open it.

Environment: Windows 11, Codex Desktop 26.601.2237.0, Rust per rust-toolchain.toml (1.95.0).

Adding a cross-link because I hit the same Windows native-host file-lock family on a newer build, with an additional Computer Use impact.

Environment observed on 2026-06-08:

• Codex Desktop: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
• Bundled plugin version: 26.602.40724

The lock/failure was against the generated bundled marketplace path rather than only the stable plugin cache:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64

Desktop logged bundled_plugins_marketplace_resolve_failed errorCode=EBUSY while trying to rmdir that directory. After that, the generated openai-bundled marketplace was left partial: only plugins\chrome remained, with no .agents\plugins\marketplace.json and no plugins\computer-use.

The immediate downstream effect was that Computer Use helper-path resolution disappeared:

computer-use native pipe helper paths changed
computer-use notify config ensure finished reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"

Restoring the generated marketplace manifest/directories from the installed app bundle made the Computer Use native pipe start again, and setupComputerUseRuntime(...) + sky.list_apps() succeeded.

Detailed timeline is in #26785. Main extra signal for this issue: a locked Chrome native host can now break more than chrome@openai-bundled; it can leave the generated openai-bundled marketplace half-materialized and disable Computer Use helper-path discovery too.

Confirming this on Windows 11 25H2 (build 26200) ARM64 — Surface Laptop 7 / Snapdragon X Elite, Codex Desktop 26.602.9276.0 (x64 under emulation).

Same root cause as reported: while Codex refreshes the bundled plugin cache, Chrome's running native host has extension-host.exe locked, so the cache backup/reinstall fails — failed to back up plugin cache entry: Access is denied. (os error 5) — leaving a partial cache and failed to load plugin: missing or invalid plugin.json plugin="chrome@openai-bundled".

Two extra findings on this setup that may help scope the fix:

1. It is not only the extension-host lock. There is also an independent staging-instability problem: on most launches the app re-stages ~\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins with only browser + latex, omitting chrome (and computer-use), even though all of them ship complete under …\WindowsApps\OpenAI.Codex_<ver>_x64__…\app\resources\plugins\openai-bundled. plugins\cache\openai-bundled\chrome\latest is a junction into that volatile staging folder, so when the stage flickers to incomplete the loader reports plugin is not installed. The stage flips complete<->incomplete every few minutes on its own.

1. Same refresh drops sibling plugins: computer-use@openai-bundled plus the openai-primary-runtime plugins (documents, spreadsheets, presentations) get logged as configured non-curated plugin no longer exists in discovered marketplaces during cache refresh.

Result: even with Chrome fully closed (no chrome.exe / extension-host.exe), the plugin still flickers working<->broken because the staging churns independently. Closing Chrome resolves the Access is denied lock half, but not the staging-completeness half.

Suggestions: (a) materialize the cached plugin into a stable version dir instead of junctioning latest into the volatile .tmp staging folder; (b) make staging atomic + verified (don't publish a stage missing shipped plugins); (c) don't uninstall configured plugins on a transient discovery miss; (d) a native ARM64 build would likely reduce the underlying file-timing races on Windows-on-ARM.

I’m experiencing the same issue on Windows in the current ChatGPT Work/Codex desktop app.

• The Chrome side panel said: “Install the app to use ChatGPT in Chrome,” even though the desktop app was installed and running.
• I removed the Chrome extension manually.
• The Chrome add-on still cannot be uninstalled from the desktop app.
• The internal plugin manager also returns: Failed to uninstall plugin.

Uploaded feedback/thread ID: 019f6631-a088-7cf0-89ce-c85142dc5b87

Additional Windows evidence from a separate Codex Desktop installation (Windows 11, app 26.715.2305.0; bundled Browser plugin 26.715.21425).

Controlled warm-restart result:

• With Avast Behavior Shield disabled, the bundled Browser plugin survived restart and remained callable.
• With Avast Behavior Shield enabled, the browser tab itself survived, but the Browser plugin reverted to an Install/unavailable state after restart.
• Avast had previously blocked a Codex-triggered Windows PowerShell process as IDP.HELU.PSE81 - Command line detection.

Important distinction: after recovery, the installed AppX source, generated runtime marketplace, and %CODEX_HOME%\plugins\cache\openai-bundled had exact SHA-256 parity; Browser/Chrome/computer-use manifests were present. No matching plugin_cache_windows_file_lock entry was found in the local Codex log for the failed restart. This suggests either (a) security software can interrupt startup refresh before Codex records a useful cache error, or (b) cache health and plugin registration/rehydration can fail independently.

A useful upstream fix/diagnostic would:

1. avoid replacing an active bundled-plugin cache;
2. stage and atomically switch refreshed content;
3. explicitly log lock owner / AV interference;
4. report disk parity separately from plugin registration/tool injection;
5. never recommend cache reinstall when parity is already healthy.

Temporary local workaround: close processes that may hold bundled-plugin files, pause the AV shield for the first launch after update, start Codex, allow bundled-plugin refresh to finish, then re-enable the shield.