Version regression; Codex Desktop bridge failure; Chrome plugin not working; Deleting .codex is not enough;

Open 💬 3 comments Opened Jun 1, 2026 by FanYu-Nijika
💡 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)?

OpenAI.Codex_26.513.4821

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

<img width="1114" height="448" alt="Image" src="https://github.com/user-attachments/assets/26619beb-5e2a-4e8c-a7fb-91017db846ca" />
Too many bugs!!!!!
no plugins chrome, no computer-use, error launching app when i tap the messages from the codex.

Over the past few days, your Codex issues were not caused by one single bug, but by several problems stacking on top of each other:

Codex Desktop seems unstable on Windows right now, especially the parts related to Chrome control, plugins, MCP/app-server, and “Computer Use”-style desktop automation.

The main bugs/issues you ran into were:

Version regression

The newer Codex versions, especially around 0.135.0, seem less stable than the older ones. You said rolling back helped before, and that makes sense. Some of the recent issues look like version-related regressions.

Codex Desktop bridge failure

Errors like:

MCP client for codex_apps failed to start

suggest that the bridge between Codex Desktop, Windows apps, Chrome, and plugins is broken or failing to start.

Chrome plugin not working

Codex could not properly control Chrome or continue from the expense page. This likely means the Chrome extension / plugin bridge was not correctly detected or started.

Deleting .codex is not enough

You deleted:

C:\Users\34494\.codex

but Codex still showed popups. That means Codex Desktop also stores state in other places, such as:

AppData
WindowsApps / Microsoft Store package data
plugin cache
background extension-host processes
Windows notification registration

So .codex is only part of the local state.

What steps can reproduce the bug?

1, about plugins: when using chrome or computer-use
2, about error launching error: when tapping messages from codex

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

FanYu-Nijika · 2 months ago

Oh sorry, the version is actually 26.527.3686.0

github-actions[bot] contributor · 2 months ago

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

  • #25511
  • #25571
  • #25284
  • #24397

Powered by Codex Action

zemeng5208 · 16 days ago

I maintain WinBridge Recovery, an independent Windows Codex Desktop local recovery/diagnostic tool: https://github.com/zemeng5208/winbridge-recovery

The point in this report that .codex deletion alone is not enough is important. On Windows, the broken Browser/Chrome/Computer Use state can be split across several user-owned layers at once: the generated bundled marketplace under .codex, versioned plugin caches and latest, %LOCALAPPDATA%\OpenAI\Codex runtime/helper files, %LOCALAPPDATA%\OpenAI\extension Native Messaging state, and Chrome/Edge registry entries. Resetting only one directory can therefore leave the remaining layers inconsistent.

WinBridge v3.1.1 was built specifically to diagnose that split state. It resolves the currently installed Microsoft Store AppX first, verifies the official bundled plugin/CUA/CLI resources, then compares the active marketplace, Browser/Chrome/Computer Use caches, latest, Node REPL/CUA runtime paths, CODEX_CLI_PATH, Native Host manifest/registry/v2 state and related helper paths. If those user-owned layers are stale or incomplete, it uses verified staging, SHA-256 checks, backups and rollback instead of requiring a destructive full .codex reset.

There are still limits: if all local layers validate but codex_apps/MCP/tool injection or a Desktop runtime protocol is failing, WinBridge should report that as upstream rather than claiming to repair it. Likewise it does not fix notification activation bugs just because they happen in the same installation.

It does not modify WindowsApps ownership/ACLs, browser policy, authentication, or product/region gates.