Skip to content

Chrome extension #28880

Open
Open

Description

@LearnerAH-ux

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

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Jun 18, 2026
  2. gqiqiang750-spec commented on Jun 26, 2026

    @gqiqiang750-spec

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

  3. zemeng5208 commented on Aug 16, 2026

    @zemeng5208

    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: zemeng5208/winbridge-recovery#4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions