Skip to content

Codex Desktop Chrome plugin unavailable even though extension and native host are installed #23322

Open

Description

@RRaikhlin

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

Codex Desktop 0.131.0-alpha.9 / Windows package OpenAI.Codex 26.513.4821.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop shows the Chrome plugin as unavailable even though the Chrome extension and native host appear to be installed correctly.

UI symptoms:

  • Plugins page shows: Chrome Unavailable in this context openai-chrome
  • Typing @chrome in the composer shows: No results
  • Chrome extension popup previously showed Disconnected

Local checks:

  • chrome@openai-chrome is enabled in config.toml
  • Chrome extension is installed and enabled
  • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome extension version: 1.1.4_0
  • Native host manifest check returns correct=true
  • Native host manifest path: C:\Users\user\AppData\Local\OpenAI\extension\com.openai.codexextension.json
  • extension-host.exe is running from: C:\Users\user.codex\plugins\cache\openai-chrome\chrome\latest\extension-host\windows\x64\extension-host.exe

Observed logs:

  • Codex logs start only backend=iab
  • I do not see Chrome/external backend startup logs
  • This looks like Codex Desktop is exposing only the in-app browser backend, not the external Chrome backend

What steps can reproduce the bug?

Feedback: 019e36fd-fd05-72d1-8605-a5f797562f52

Steps to reproduce:

  1. Install/enable the openai-chrome plugin in Codex Desktop.
  2. Install the Chrome extension.
  3. Restart Codex Desktop.
  4. Open Codex Desktop Plugins page.
  5. Observe that Chrome is listed as unavailable in this context.
  6. Start a chat and type @chrome.
  7. Observe that @chrome does not appear and the composer says No results.

Additional local verification already performed:

  • check-extension-installed.js reports installed=true, registered=true, enabled=true
  • check-native-host-manifest.js reports correct=true
  • extension-host.exe process is running

What is the expected behavior?

Chrome plugin should be available in this context. @chrome should appear in the composer, and Codex Desktop should be able to connect to the Chrome extension / external Chrome backend.

Additional information

Please check whether this Windows build/account has browser_use_external disabled, or whether the Desktop app/plugin/runtime versions are mismatched.

Activity

  1. added
    appIssues related to the Codex desktop app
    on May 18, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    skillsIssues related to skills
    on May 18, 2026
  3. zemeng5208 commented on Aug 14, 2026

    @zemeng5208

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

    The interesting part of this report is the split between “installed/healthy on disk” and “unavailable in this context”: the extension is enabled, the native-host check passes, and extension-host.exe is running, but Desktop starts only the iab backend and @Chrome is absent.

    WinBridge checks for version/source drift across the active Codex home, bundled marketplace, plugin cache/latest, native-host manifest + registry state, and the cua_node/node_repl runtime rather than assuming a successful native-host check means the whole integration is coherent. That is useful when an app update leaves different layers on different plugin/runtime generations.

    If everything local is already coherent and this account/build is simply not being provisioned with browser_use_external, WinBridge cannot and should not bypass that feature/context gating. It should return an upstream/availability diagnosis instead of changing healthy files.

    If anyone still has this exact “native host correct + only iab + @chrome unavailable” state and tries WinBridge, please report the outcome at zemeng5208/winbridge-recovery#4. I am collecting successful, partial, and failed results equally.

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 workingskillsIssues related to skillswindows-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