›_ Codex Issues
Codex Issues / #23831

Chrome plugin disappeared from Codex App marketplace after update; cached browser-client is not trusted

Open 💬 6 comments Opened May 21, 2026 by baizhufbb
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #22951
  • #22598
  • #22400
  • #23414
  • #23322

Powered by Codex Action

feitian124 · 1 month ago

I met same problem in codex app 26.527.31326.
i did not see the chrome, broswer use, computer use even after restart computer.
and i tried uninstall/install codex app issue still exits.

but i follow the above process metioned by this issue reporter after restart:
Close Chrome completely.
Close Codex completely.
Start Codex again.
it come out.

dingjianhui123-create · 1 month ago

Additional Windows recovery datapoint from another affected machine. This is not an official fix, but it may help narrow down the failure mode.

Environment:

  • Windows x64
  • Codex App 26.527.3686.0
  • codex-cli 0.135.0-alpha.1
  • bundled browser, chrome, and computer-use plugins at 26.527.31326

Symptoms observed:

  • browser-client is not trusted
  • privileged native pipe bridge is not available
  • Computer Use also failed with native pipe unavailable/path unavailable errors
  • codex plugin list --marketplace openai-bundled could show plugins as enabled, while runtime bootstrap still failed
  • after a restart, Browser/Chrome regressed to not installed because local plugin cache directories/manifests were missing

What recovered this machine:

  1. Closed Codex/Chrome where possible before cache repair, because live Node/Codex/plugin smoke-test processes can lock native files under the plugin cache.
  2. Restored missing browser, chrome, and computer-use plugin cache directories/manifests from the bundled marketplace source. Avoided overwriting already-loaded native files while Codex was running.
  3. Ensured these plugin blocks existed and stayed enabled:
[plugins."browser@openai-bundled"]
enabled = true

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

[plugins."computer-use@openai-bundled"]
enabled = true
  1. Added runtime env values to the local node_repl MCP server:
[mcp_servers.node_repl.env]
NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S = "<sha256 values for the installed bundled browser/chrome/computer-use client scripts>"
SKY_CUA_NATIVE_PIPE_DIRECTORY = "\\\\.\\pipe\\codex-computer-use-<current-session-id>"

The important part was not hard-coding someone else's values. The SHA-256 list was computed from the installed plugin client files on that machine, and the Computer Use pipe was discovered from the current live \\.\pipe\codex-computer-use-* pipe.

  1. Because the Computer Use pipe changes after Codex restarts, I added a local Windows scheduled-task watchdog that runs once per minute and only writes when needed. It:
  • restores missing bundled plugin cache/manifests if absent
  • recomputes trusted client SHA-256 values from installed plugin files
  • refreshes SKY_CUA_NATIVE_PIPE_DIRECTORY to the current live pipe
  • keeps the three bundled plugins enabled
  • creates a timestamped backup before changing config.toml
  • uses a mutex to avoid concurrent writes

Verification after repair:

  • config.toml parsed successfully
  • codex mcp get node_repl showed the expected env entries
  • codex plugin list --marketplace openai-bundled showed Browser, Chrome, and Computer Use as installed, enabled
  • Browser smoke test succeeded with both Chrome and Codex In-app Browser listed
  • Chrome smoke test succeeded when using the dynamic browser id returned by agent.browsers.list()
  • Computer Use smoke test succeeded with sky.list_apps() and sky.list_windows()

My interpretation:

  • For a simple marketplace/cache mismatch, the "fully close Chrome and Codex, start Codex first, wait for plugin refresh, then reopen Chrome" recovery is safer and should be tried first.
  • In this case that was not enough, because plugin cache/manifests, trusted client hashes, and a session-specific Computer Use pipe all had to be kept in sync.
  • The ideal official fix would make this unnecessary by ensuring bundled plugin cache regeneration, trusted browser-client injection, and native-pipe discovery are handled atomically by Codex Desktop instead of relying on user-maintained config.toml repair scripts.

Sanitized write-up of the local repair is here:

https://gist.github.com/dingjianhui123-create/9c3c2b83c2a45c2ef32f9991e712edba

vigyaanvest-pixel · 1 month ago

Thanks for all the suggestions. An additional step that worked for me was:

  1. Find extentions-host.ext from windows task manager - right click to find it location - in my case, this turned out to be under %userprofile%/.tmp. I killed the process and deleted contents under this dir. After codex restart, I could see the chrome plugin appearing again.
m13v · 1 month ago

trust keys on the bundled-marketplace temp path, not the cache, so an update wiping .tmp orphans the cached browser-client.

iwomen · 21 days ago

yeah,I met same problem this morning after I updated the codex app

Then i follow the above process metioned by this issue reporter after restart:
Close Chrome completely.
Close Codex completely.
Start Codex again.
and it worked.