›_ Codex Issues
Codex Issues / #28880

Chrome extension

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

019ed979-2b27-7123-af0e-f7c23dc67597

Problem

Codex desktop cannot connect to the Codex Chrome Extension on Windows, even though the Chrome extension is installed and enabled.

Environment

  • OS: Windows
  • Browser: Google Chrome
  • Codex desktop app: reinstalled, issue persists
  • Codex Chrome Extension: installed from Chrome Web Store and enabled
  • Chrome extension permissions:
  • Site access: On all sites
  • “Communicate with cooperating native applications” permission is present
  • Extension is pinned/enabled

What I tried

  1. Uninstalled and reinstalled Codex desktop.
  2. Confirmed the Codex Chrome Extension is installed and enabled in chrome://extensions.
  3. Closed and reopened both Codex and Chrome.
  4. Ran Windows permission repair for the OpenAI local app folder:
takeown /F "$env:LOCALAPPDATA\OpenAI" /R /D Y
icacls "$env:LOCALAPPDATA\OpenAI" /grant "$($env:USERDOMAIN)\$($env:USERNAME):(OI)(CI)F" /T


HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27962
  • #27866
  • #27792
  • #28753
  • #28033

Powered by Codex Action

gqiqiang750-spec · 2 months ago

您现在这个问题已经解决了吗

zemeng5208 · 12 days ago

I maintain WinBridge Recovery, an independent Windows recovery/diagnostic tool for Codex Desktop Browser / Chrome / Computer Use local state.

This symptom is in its core diagnostic scope: Chrome extension installed/enabled, Codex Desktop reinstalled, but the Chrome bridge still does not connect. A reinstall does not necessarily clear or reconcile the user-side plugin cache, latest targets, Native Host manifest/registry/v2 metadata, or local runtime/app-server paths.

One safety point: I would avoid continuing with broad takeown / icacls permission changes as a recovery strategy. WinBridge deliberately does not take ownership of WindowsApps, disable policy, or weaken ACLs. It compares the current official AppX package with the user-owned Browser/Chrome/Computer Use state and, where there is a stale/partial mismatch, rebuilds only the writable state with staging, SHA-256 verification, backup and rollback.

For Chrome specifically it checks the bundled marketplace/cache/version/latest, the Native Messaging manifest and HKCU registration, chrome-native-hosts-v2.json, and the runtime/app-server paths they reference. If all of those are healthy and the extension still cannot establish the Codex backend, that is useful evidence that the remaining failure is upstream rather than a permissions problem.

If anyone on this issue tests it, both success and failure reports help define the real boundary: https://github.com/zemeng5208/winbridge-recovery/issues/4