codex - 💡(How to fix) Fix Chrome plugin disappeared from Codex App marketplace after update; cached browser-client is not trusted

After a Codex Desktop update on Windows, the Chrome plugin disappeared from the Codex App plugin marketplace.

This was not originally triggered by a normal restart. The trigger in my case was a Codex Desktop update. Restarting only became part of the recovery process.

My observed problem

After the update:

1. The Chrome plugin was no longer visible in the Codex App plugin marketplace.
2. Because the Chrome plugin was not available in the app, the assistant could not use external Chrome for browser automation.
3. Cached Chrome plugin files still existed under paths like:

C:/Users/admin/.codex/plugins/cache/openai-bundled/chrome/.../scripts/browser-client.mjs

1. But loading from the cached path failed with:

browser-client is not trusted
privileged native pipe bridge is not available

1. The trusted bundled marketplace temp path was missing:

C:/Users/admin/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/chrome/scripts/browser-client.mjs

So the visible symptom was: the Chrome plugin disappeared from the Codex App plugin marketplace. The cache/trusted-path observations are additional diagnostics, not the original user-facing symptom.

Recovery that worked

The issue was fixed by fully closing Chrome/Codex and then starting Codex again.

What I did:

1. Close Chrome completely.
2. Close Codex completely.
3. Start Codex again.
4. Wait for the bundled plugin refresh / marketplace cache to regenerate.

At this point, the Chrome plugin had already reappeared in the Codex App plugin marketplace. Reopening Chrome afterward was only needed to restore actual external Chrome control / extension-backed browser automation.

On Windows, it may also help to verify that no Chrome/native-host processes are still running. For example, in PowerShell:

Get-Process chrome, extension-host -ErrorAction SilentlyContinue | Select-Object Id, ProcessName, Path

If they are still running after normal shutdown, terminate the leftovers:

Get-Process chrome, extension-host -ErrorAction SilentlyContinue | Stop-Process -Force

Codex itself should also be fully closed before starting it again. I used the normal app close flow. If using PowerShell, the simple version is:

Get-Process Codex -ErrorAction SilentlyContinue | Select-Object Id, ProcessName, Path
Get-Process Codex -ErrorAction SilentlyContinue | Stop-Process -Force

Then start Codex first and wait for plugin refresh. In my case, the Chrome plugin reappeared in the plugin marketplace at this point. Open Chrome afterward only if external Chrome control is needed.

After this, the trusted marketplace path reappeared, and external Chrome became available again as an extension browser after Chrome was reopened.

Why this may connect several existing issues

This seems to connect multiple symptoms that are currently split across separate issues:

Plugin marketplace / Chrome missing

• #21788: Chrome plugin missing from Plugins on Windows.
• #21862: Chrome plugin missing from Plugin Directory.
• #22051: local Chrome plugin files exist, but Chrome is missing from Codex Plugins.
• #22951: Chrome plugin / computer use disappeared.

These match my main user-visible symptom: Chrome disappeared from the Codex App plugin marketplace.

Windows cache / native host / file lock

• #22114: Chrome native host can lock the plugin cache during Codex restart, corrupting or partially materializing the Chrome plugin cache.
• #21670: Chrome plugin / Browser Use setup hangs; uninstall fails with os error 5.
• #22462: extension/native host checks pass, but setup hangs and logs show Windows plugin cache lock failures.

These may explain how the cache/marketplace state becomes inconsistent, especially when extension-host.exe is running from the plugin cache.

Trusted browser-client / native pipe bridge

• #21781: browser-client is not trusted and privileged native pipe bridge is not available.
• #23414: cached plugin path and trusted bundled marketplace path disagree on the browser-client entrypoint.

This is closest to my additional diagnostic evidence: cached files existed, but Codex would not trust them; the trusted marketplace temp path had to be regenerated.

UI/runtime mismatch

• #21791: @chrome can be selected, but Chrome is not exposed in active tools.
• #22888: @chrome mention does not reliably load or surface the Chrome skill.
• #22424: Chrome works interactively but is unavailable in another runtime context.

These are related but not exactly the same as my initial symptom. In my case, the first visible problem was that the Chrome plugin disappeared from the plugin marketplace.

Hypothesis

The failure may not be just “Chrome plugin missing”.

It looks more like a state mismatch between:

• bundled marketplace cache
• installed plugin cache
• trusted temporary marketplace path
• Chrome native host / extension-host.exe
• active tools exposed to the current thread

In my case, a Codex Desktop update left the cached Chrome plugin files present but untrusted, while the trusted bundled marketplace path was missing. Closing Chrome/Codex and then starting Codex again regenerated the trusted path and restored the Chrome plugin in the Codex App plugin marketplace. Reopening Chrome afterward restored external Chrome control.