Codex Desktop Windows browser extension is disconnected and Chrome plugin is not injected after cache rebuild

Open 💬 5 comments Opened May 27, 2026 by 15230745073

💡 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)?

26.521.10419

What subscription do you have?

business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After updating Codex Desktop on Windows, the Chrome/Edge browser integration no longer works.

I am using Microsoft Edge, and this setup worked normally before the Codex Desktop update. The Codex browser extension now shows Not connected. In a new Codex thread, when I type the @ character and search for Chrome, the Chrome plugin cannot be found in the plugin list.

I also tried removing or resetting the browser plugin from Codex Desktop, but the app reports that plugin uninstall/removal failed. This leaves the browser integration stuck in a disconnected state that cannot be reset from the app UI.

I verified several local components:

The native messaging manifest exists and appears normal:
C:\Users\<user>\AppData\Local\OpenAI\extension\com.openai.codexextension.json
Edge policy checks returned no blocking configuration.
I renamed the user-level bundled Chrome plugin cache:
C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome
Codex Desktop rebuilt the cache successfully.
The rebuilt cache/plugin version is now 26.519.81530.
The browser plugin version also reports 26.519.81530.

However, Codex Desktop still does not connect the browser integration, and the Chrome plugin is still unavailable in a new thread.

This appears to be a Codex Desktop-side browser plugin registration, connection-state synchronization, or tool-injection issue on Windows, rather than only a stale bundled plugin cache or missing native messaging manifest.

What steps can reproduce the bug?

Use Codex Desktop on Windows.
Use Microsoft Edge with the Codex browser extension.
Update Codex Desktop.
Open Codex Desktop and go to the browser / Chrome skill or plugin area.
Observe that the browser integration shows as not connected.
Open the Edge extension popup.
Observe that the extension shows Not connected.
Try to remove or reset the browser plugin from Codex Desktop.
Observe that removal/uninstall fails.
Rename the user-level bundled Chrome plugin cache at C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome.
Restart Codex Desktop.
Observe that Codex Desktop rebuilds the browser plugin cache successfully.
Confirm the rebuilt plugin/cache version is 26.519.81530.
Start a new Codex thread.
Type the @ character and search for Chrome in the plugin list.
Observe that the Chrome plugin cannot be found or invoked from the plugin list.

What is the expected behavior?

After the browser extension and bundled plugin cache are installed or rebuilt correctly, Codex Desktop should connect the Chrome/Edge browser integration and expose the Chrome browser-control plugin in new threads.

If the browser integration is broken or partially installed, Codex Desktop should allow the user to remove or reset the integration successfully from the app UI.

If Microsoft Edge is not supported, Codex Desktop should clearly state that only Google Chrome is supported, instead of leaving the browser plugin in a disconnected and unremovable state.

Additional information

Environment:

Product: Codex Desktop
OS: Windows
Browser: Microsoft Edge
Codex Desktop version: [fill in About Codex version]
Edge version: [fill in edge://settings/help version]
Codex browser extension version: [fill in edge://extensions version]

Native messaging host:

Host name: com.openai.codexextension
Manifest path: C:\Users\<user>\AppData\Local\OpenAI\extension\com.openai.codexextension.json
Manifest status: exists and appears normal

Registry / policy checks:

Edge policy paths checked:
HKCU:\Software\Policies\Microsoft\Edge
HKLM:\Software\Policies\Microsoft\Edge
Result: no output / no blocking native messaging policy found

Bundled plugin cache:

Original user-level cache path:
C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome
Action taken:
Renamed the cache directory and restarted Codex Desktop.
Result:
Codex Desktop rebuilt the cache successfully.
New cache/plugin version:
26.519.81530
Browser plugin version:
26.519.81530

Relevant protected app package path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\chrome

I did not manually delete files under C:\Program Files\WindowsApps because it is a protected Windows app package directory.

Observed final state:

Codex browser extension in Edge: Not connected
Codex Desktop browser/Chrome skill: not connected
Remove/reset from Codex Desktop: fails
New Codex thread: Chrome plugin cannot be found after typing the @ character and searching for Chrome
Bundled Chrome/browser plugin cache: rebuilt successfully to 26.519.81530
Native messaging manifest: exists and appears normal
Edge policy: no blocking policy found

Impact:

The browser-control workflow is no longer usable from Codex Desktop.
The Chrome plugin is not available in new threads even after the bundled plugin cache is rebuilt.
The browser integration cannot be repaired from the Codex Desktop UI because the remove/reset flow fails.
Users cannot easily tell whether the failure is caused by the browser extension, native messaging host, bundled plugin cache, or Codex Desktop plugin injection state.

Possible root cause:

This appears to be a Codex Desktop Windows-side browser plugin registration or tool-injection bug.
The bundled browser plugin cache can be rebuilt successfully, but Codex Desktop still does not connect the browser extension or expose the Chrome browser-control plugin in new threads.
The uninstall/reset flow also fails, leaving the browser integration stuck in an unrecoverable disconnected state.

Questions:

Does Codex Desktop refresh browser plugin registration after the bundled plugin cache is rebuilt?
Can the Chrome browser-control plugin fail to be injected into new threads even when the bundled plugin cache exists and reports the current version?
Is Microsoft Edge expected to be supported for this browser extension workflow?
If Microsoft Edge is not supported, can Codex Desktop show a clear unsupported-browser message instead of a generic disconnected state?
Can the plugin remove/reset flow be made resilient enough to repair this state from the Codex Desktop UI?

Formatting note:

This issue avoids writing the raw plugin invocation as a single token because some UIs may auto-link or render it incorrectly.
The exact user action is typing the @ character followed by Chrome.
This draft intentionally avoids nested Markdown code blocks to reduce the chance of truncation when pasted into GitHub issue forms.

Original Chinese context:

更新 Codex Desktop 后，之前可正常使用的 Edge/Codex Chrome 插件变为未连接；重建 openai-bundled\chrome 缓存后版本已更新到 26.519.81530，但 Codex Desktop 仍无法连接插件，新会话中输入 @ 后也找不到 Chrome 插件。

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

#23805
#23322
#23831
#23632

Powered by Codex Action

stevenworld75 · 2 months ago

Sharing a field workaround that fixed this on my Windows desktop after the recent Codex Desktop update. This is not an official OpenAI fix, but it may help when the extension is installed/reinstalled and still shows not connected.

In my case, the extension itself was not the only problem. Two local runtime issues were blocking Codex:

ode_repl failed before browser automation with codex/sandbox-state-meta: missing field sandboxPolicy.

Computer Use tried a native-pipe-only path, but the expected codex-computer-use-* pipe was missing. The bundled codex-computer-use.exe helper still worked over stdio.

What fixed it locally:

Wrapped

ode_repl.exe with a shim that injects the legacy sandboxPolicy field and forwards to the original runtime.

Refreshed browser/chrome MCP and extension-host config to point at the current runtime/CLI paths.
Patched computer-use-client.mjs to try native pipe first, then fall back to the shipped stdio helper.
Added an idempotent repair script and optional restart watchdog.

Verification:

Chrome extension control opened https://example.com/ and read title Example Domain.
Computer Use sky.list_apps() returned 40 apps.
The repair script rerun reported Browser runtime repair: already current.

Full copy/paste prompt and repair notes:
https://gist.github.com/stevenworld75/6c59315b858807a1b6d6a238b1db69f6

Use carefully: back up first, do not hard-code paths from my machine, and keep it version-aware so it does not overwrite a future upstream fix.

sickn33 · 1 month ago

I can confirm a similar failure on macOS with Microsoft Edge after a Codex Desktop update. In my case, reinstalling or reloading the Edge extension was not enough: the Codex-side extension-host registration was stale.

Environment:

Codex Desktop: 26.707.72221
Browser: Microsoft Edge
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Architecture: macOS arm64

What I found locally:

The current bundled browser plugin was under ~/.codex/plugins/cache/openai-bundled/chrome/26.707.72221.
~/.codex/plugins/cache/openai-bundled/chrome/latest still pointed to the previous, deleted version 26.707.71524.
~/.codex/chrome-native-hosts-v2.json still referenced the old version and old browser-client/extension-host paths.
The current extension-host directory was missing extension-host-config.json.
The Edge native-messaging manifest pointed to the broken latest path.

The temporary workaround that restored the integration was:

Detect the newest complete plugin version (checking that the browser client and extension-host binary exist).
Repoint chrome/latest to that version.
Create the matching extension-host-config.json with the current browser-client path, Codex CLI path, Node/node-repl paths, extension ID, and proxy settings.
Update chrome-native-hosts-v2.json and the Edge native-messaging manifest to use the current stable latest path.
Toggle the Edge extension off and on once to reload it.
Verify the result by listing and controlling an Edge tab through the browser bridge and reading its title/URL.

This restored Edge control successfully.

To survive future Codex updates, I added a small idempotent macOS LaunchAgent that runs at login and only when the Codex browser-plugin cache or chrome-native-hosts-v2.json changes (WatchPaths with a short throttle). It is a short-lived repair script, not a resident process and not a 30-second polling loop.

This is only a temporary workaround: it relies on private .codex paths and should be removed once Codex performs an atomic cache/latest update and refreshes the native-host registration itself. The fact that this fixes the issue suggests that the update path can leave the native-host/config pointers stale, rather than the Edge extension itself being fundamentally broken.

l970421y-dotcom · 20 days ago

I can confirm this still occurs on Windows with Google Chrome.

Environment:

Codex Desktop: 26.803.5235.0 (Windows x64)
Chrome extension: 1.2.27236.6274, installed and enabled
Bundled plugin version: 26.803.41515

Observed:

The Chrome extension side panel fails to connect.
New Codex tasks do not receive the node_repl / Chrome control tools.
An explicit @Chrome request can only report that the Chrome interface is unavailable.

Recovery attempts:

Fully restarted Codex Desktop.
Verified the native-messaging manifest and extension origin.
Repointed a stale native-host reference from 26.707.72221 to the current Chrome plugin host 26.730.61639 and confirmed the new extension-host process launched.
Enabled/reprovisioned Computer Use and tested again in a new task.

The failure persists: Chrome/Computer Use tools are still not injected into the task, and the Chrome side panel also fails.

Expected:
New Codex tasks should receive the Chrome/node_repl tools, and the extension side panel should connect.

zemeng5208 · 13 days ago

Disclosure: I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

What stands out in this report is that rebuilding only ~/.codex/plugins/cache/openai-bundled/chrome succeeded, yet the extension still shows Not connected and new threads do not expose the Chrome plugin. That is exactly why WinBridge does not treat “cache directory exists/current” as proof that the integration is healthy.

On Windows it compares the installed AppX source with the generated bundled marketplace, versioned plugin cache/latest, native-host manifest + registry/v2 state, cua_node/node_repl runtime references, and the active Codex home. If a user-writable layer is stale or internally inconsistent, it backs up first and repairs from the officially installed package with verification and rollback data.

There is also an important negative case here: if the cache, native host, runtime and active config all validate after repair but Desktop still refuses to inject the Chrome backend into a fresh thread, WinBridge should report that as an upstream registration/tool-injection problem rather than claiming success.

If anyone with the same “cache rebuilt but Chrome still absent/not connected” state tries it, please report the result at https://github.com/zemeng5208/winbridge-recovery/issues/4. A short ✅ worked / 🟡 partial / ❌ unchanged report is more useful to me than a star because it tells me which failure class is actually recoverable.