›_ Codex Issues
Codex Issues / #30729

Chrome / Computer Use plugin disappeared although bundled plugin is installed

Open 💬 5 comments Opened Jun 30, 2026 by ldc9060-arch
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.623.70822

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

Summary

The Chrome / Computer Use plugin disappeared from the Codex Desktop application after updating to the latest version.

Previously the feature worked correctly.

Searching for:

  • Chrome
  • Browser
  • Computer Use

returns "No plugins found" in the plugin marketplace.

Investigation

I investigated the issue before reporting it.

Verified:

  • Codex Desktop updated to the latest version
  • .codex-global-state.json exists
  • backup state exists
  • browser plugin exists
  • chrome plugin exists
  • computer-use plugin exists
  • plugin cache is present
  • bundled plugin packages are present

The plugin files are installed locally, but they are not visible in the UI.

I also prepared a PDF investigation report with screenshots.

What steps can reproduce the bug?

  1. Open Codex Desktop.
  2. Open Plugins.
  3. Search for "Chrome".
  4. Search for "Browser".
  5. Search for "Computer Use".
  6. No plugin is found although the bundled plugin files exist locally.

What is the expected behavior?

The Chrome / Computer Use plugin should appear in the plugin list and be available for use.

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30270
  • #30366
  • #30259

Powered by Codex Action

ldc9060-arch · 1 month ago

Update:

After rebooting Windows, the issue disappeared.

The Chrome, Browser and Computer Use plugins are now visible again.

It looks like the bundled plugins were already installed locally, but Codex Desktop did not recognize them until after a full system reboot.

Hopefully this helps identify the root cause.

yundongbanxia · 1 month ago

A reboot can make the bundled plugins appear if the local staging/cache was already valid, but in my case the deeper issue was the WindowsApps source file state.

The useful check was:

$pkg = (Get-AppxPackage OpenAI.Codex).InstallLocation
cipher /c "$pkg\app\resources\plugins\openai-bundled\plugins\computer-use\.codex-plugin\plugin.json"

When the source showed encrypted / Application Protected behavior, Codex could not reliably relocate bundled plugins and node_repl was not injected. After reinstalling so the source showed U plugin.json, Computer Use and Browser became stable across multiple restarts.

NotoriousNDC · 1 month ago

same issue - 019f5dac-6042-7652-b369-7a6d9e8da34d

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop plugin/runtime state failures: https://github.com/zemeng5208/winbridge-recovery

This thread is a good example of why I built the tool around state consistency, not just “reinstall the plugin.” A reboot can recover the UI when the package, generated marketplace and cache are already valid, but the Application Protected data point in this thread shows the deeper failure class: Store resources can exist while Desktop cannot reliably materialize them into the user-side marketplace/runtime.

WinBridge checks those layers separately: current AppX package/resources -> generated/managed bundled marketplace -> versioned plugin cache and latest -> CUA/runtime/Native Host state. If everything is already consistent after a reboot, it skips repair. If the generated marketplace/runtime is partial, stale or version-split, it can rebuild the user-owned copies from the already installed official package with verified staging and SHA-256 checks.

Application Protected/EFS handling is still explicitly experimental in the project, so I am not claiming every affected Store install is solved. WinBridge also will not fix an upstream trusted-tool injection failure when all local layers are already healthy. It does not modify WindowsApps ownership, ACLs, encryption state, package files, or signatures.