Skip to content

Codex Chrome plugin shows Connected on Windows, but Codex cannot control Chrome and initialization times out #22264

Closed as duplicate
Closed as duplicate
Codex Chrome plugin shows Connected on Windows, but Codex cannot control Chrome and initialization times out#22264
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't working

Description

@chenyingjie123456-tech
chenyingjie123456-tech
opened on May 12, 2026

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

Unknown, latest Windows desktop app reinstalled on 2026-05-12

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

I’m using the Codex desktop app with the Chrome plugin on Windows. The Chrome extension popup shows Connected, but Codex still cannot read Chrome tabs or control the page.

Confirmed details:

  • The Chrome extension is installed and enabled, version v1.1.4
  • The Windows Native Messaging Host manifest exists:
    C:\Users\chen\AppData\Local\OpenAI\extension\com.openai.codexextension.json
  • The registry key exists:
    HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
  • The manifest points to:
    C:\Users\chen\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe
  • On the Codex side, calling browser.user.openTabs() keeps timing out
  • Reinstalling Codex, restarting Chrome, restarting Codex, and clearing extension-host.exe processes did not fix the issue
  • Chrome can be opened to a URL through a system command, but Codex cannot take control of the page, click elements, upload files, or read tabs

What steps can reproduce the bug?

  1. Install or reinstall the Codex desktop app on Windows.
  2. Enable/install the Chrome plugin.
  3. Open Chrome and confirm the Codex Chrome extension popup shows Connected.
  4. Ask Codex to control Chrome, for example to open tabs or interact with a logged-in website.
  5. Codex attempts to initialize the Chrome browser control backend.
  6. The operation times out, for example when trying to call browser.user.openTabs().

What is the expected behavior?

Codex should be able to read the current Chrome tabs and control the page through the Chrome plugin when the extension shows Connected.

Additional information

The Chrome extension shows Connected, but Codex cannot read tabs or control Chrome. The browser control module times out during initialization.

Activity

  1. chenyingjie123456-tech
    added
    appIssues related to the Codex desktop app
    on May 12, 2026
  2. etraut-openai
    added
    bugSomething isn't working
    browser
    on May 14, 2026

  3. qingci2014 commented on May 15, 2026

    @qingci2014
    qingci2014
    on May 15, 2026

    I am seeing what looks like the same Chrome plugin failure on Windows.

    Related issue:

    Environment

    • OS: Windows
    • Codex Desktop on Windows
    • Chrome plugin: chrome@openai-bundled 0.1.7
    • Codex Chrome Extension version: 1.1.4 / 1.1.4_0
    • Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
    • Chrome profile: Default
    • Native host name: com.openai.codexextension
    • Codex runtime user: WIN-0H28B45NIHJ\CodexSandboxOffline

    Diagnostics

    The extension and native host appear to be installed and connected:

    • Native host registry key exists and passes check:
      HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

    • Native host manifest exists:
      C:\Users\Administrator\AppData\Local\OpenAI\extension\com.openai.codexextension.json

    • Manifest points to:
      C:\Users\Administrator\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

    • Chrome profile permissions were fixed so CodexSandboxOffline can read:
      C:\Users\Administrator\AppData\Local\Google\Chrome\User Data

    • Extension check reports:

      • installed=true
      • registered=true
      • enabled=true
      • disabled=false

    • Chrome extension DevTools storage reports:

      • NATIVE_HOST_STATUS.state = "connected"
      • hostName = "com.openai.codexextension"
      • reconnectAttempt = 0

    • extension-host.exe is running.

    Failure

    Even though the extension reports that the native host is connected:

    • agent.browsers.list() can see the Chrome backend.
    • agent.browsers.get(Chrome extension backend) times out indefinitely.
    • browser.user.openTabs() cannot be reached because backend acquisition hangs.

    I have already tried:

    • Restarting Windows
    • Restarting Chrome
    • Restarting Codex
    • Restarting extension-host.exe
    • Toggling the Chrome extension
    • Toggling the Codex Chrome skill
    • Reinstalling the Codex Chrome plugin

    None of these fixed the issue.

    Conclusion

    This does not look like a registry, Chrome profile permission, or extension installation problem.

    The Chrome extension and native host appear to connect successfully, but Codex Desktop still cannot acquire the Chrome extension backend. It looks more like a Codex Desktop / Chrome plugin runtime issue.

  4. WMIL111 commented on May 21, 2026

    @WMIL111
    WMIL111
    on May 21, 2026 – with ChatGPT Codex Connector

    Adding another Windows reproduction from Codex Desktop.

    Environment:

    • Windows Codex Desktop package: OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0
    • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
    • Chrome extension version: 1.1.4_0
    • Chrome plugin cache path: %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.519.21041

    Observed behavior:

    • Mentioning @chrome is recognized by Codex, but the browser-control / node_repl tools are not exposed to the conversation.
    • Tool discovery after @chrome only returns unrelated tools such as GitHub/Canva, not the Chrome browser-client execution tool.
    • As a result, Codex cannot actually open/control Chrome tabs via the Chrome plugin.

    Diagnostics already checked:

    • Chrome is running.
    • Codex Chrome Extension is installed and enabled in the Chrome Default profile.
    • Native messaging host is registered at HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension.
    • Manifest exists at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json.
    • Manifest has the expected host name and allowed origin: chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/.
    • extension-host.exe is running from the Chrome plugin cache path.
    • Running the plugin diagnostic scripts with a working Node reports extension installed/enabled and native host manifest correct.

    Additional note:

    • The Store-packaged Codex node.exe under C:\Program Files\WindowsApps\...\app\resources\node.exe returned Access is denied when invoked directly from PowerShell, while an alternate Codex runtime Node under %USERPROFILE%\.cache\codex-runtimes\...\node.exe works. Prepending that working Node to the user PATH made node -v succeed, but @chrome still did not expose the Chrome browser-control tools.

    Recovery attempts that did not fix it:

    • Windows app Repair and Reset for Codex.
    • Removing/reinstalling the Chrome plugin.
    • Closing Chrome and stopping extension-host.exe before reinstalling the plugin.
    • Starting a fresh Codex conversation after reinstalling.

    Current conclusion: local Chrome extension and native host appear healthy, but Codex Desktop plugin/tool routing is not exposing the Chrome browser-client/node_repl execution tools to the conversation after @chrome.

  5. zhaijianxiao-hue commented on May 22, 2026

    @zhaijianxiao-hue
    zhaijianxiao-hue
    on May 22, 2026 – with ChatGPT Codex Connector

    I saw a similar Windows pattern: the Chrome extension could work right after install, but later Codex would no longer expose/control Chrome even though the extension popup looked connected.

    The workaround that consistently helped locally was:

    1. Fully quit Codex.
    2. Fully quit Chrome.
    3. In Task Manager, make sure chrome.exe and extension-host.exe are gone.
    4. Start Codex first and wait until the Chrome/Browser plugins are visible.
    5. Start Chrome after that.

    I wrote a short troubleshooting guide here:
    https://treasure-lung-30f.notion.site/Codex-Chrome-Extension-on-Windows-Setup-and-Troubleshooting-Guide-36830cb58ab8816eb0a4e8b93153a94c

    Not an official fix, just a user-tested workaround in case it saves someone time.

  6. gabrielmontufar commented on May 23, 2026

    @gabrielmontufar
    gabrielmontufar
    on May 23, 2026 – with ChatGPT Codex Connector

    I can reproduce a closely related Windows Chrome plugin failure in Codex Desktop.

    Environment / local state:

    • Windows, Codex Desktop with chrome@openai-bundled enabled.
    • Chrome plugin cache version: 26.519.41501.
    • Codex Chrome Extension installed and enabled in the selected Chrome profile (Profile 3), extension version 1.1.5_0.
    • Extension id: hehggadaopoacecdllhhajmbjkdcmajg.
    • Native host manifest exists at %USERPROFILE%\AppData\Local\OpenAI\extension\com.openai.codexextension.json and points to %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe.
    • reg query HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension shows the default value pointing to that manifest.

    Observed behavior:

    • When Codex tries to communicate with an existing Chrome tab, Chrome displays the banner: "Codex" started debugging this browser.
    • The controlled tab then gets stuck on a black/loading state with a spinner. This is reproducible even with a new Codex session.
    • The issue can create duplicate tabs for the same ChatGPT conversation.
    • Restarting extension-host.exe and resetting the Node REPL/browser runtime allows browser.user.openTabs() to work again temporarily, but the stuck tab remains associated with an old browser session.

    Concrete errors observed:

    native pipe is closed

    and then, when trying to reclaim the stuck tab:

    Tab 723868938 is already part of browser session 019e5481-33dd-7d32-82ef-d1f5cdc09bb9

    The current session can list tabs and can claim some duplicate tabs, but one stuck tab remains permanently owned by the previous browser session. Calling browser.tabs.finalize({ keep: [] }) from the current session does not release that old tab because browser.tabs.list() is empty for the current session.

    One additional oddity: direct PowerShell/.NET registry reads show the native messaging host key exists and has the correct default value, but the plugin diagnostic script still reported:

    {
  "registryManifestPath": null,
  "correct": false,
  "problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension"
}

    So this looks like a stale browser-session ownership / native pipe lifecycle bug, plus possibly an inconsistent Windows registry read in check-native-host-manifest.js.

  7. ax-openai commented on Jun 12, 2026

    @ax-openai
    ax-openai
    on Jun 12, 2026 – with ChatGPT Codex Connector

    Closing as a duplicate of #21698.

  8. ax-openai
    closed this as duplicateon Jun 12, 2026

  9. zemeng5208 commented on Aug 14, 2026

    @zemeng5208
    zemeng5208
    on Aug 14, 2026 – with ChatGPT Codex Connector

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

    This thread is a good boundary case for a local repair tool. Some reproductions show the Chrome extension, registry/manifest and extension-host.exe all present — in one case the Chrome backend is even visible — but backend acquisition or the browser-control/node_repl tool route still hangs or disappears.

    WinBridge checks whether that apparently healthy surface is hiding mixed Windows state: active CODEX_HOME, bundled marketplace, concrete plugin cache/latest, native-host manifest + registry/v2 state, and cua_node/node_repl runtime references are compared against the official installed package together. Reinstalling just the Chrome plugin does not necessarily repair all of those layers.

    But if those local layers validate and the host really is connected while agent.browsers.get("extension") still times out, WinBridge should not claim to fix a Desktop routing/backend handshake. It reports that boundary as upstream rather than repeatedly rewriting a healthy native-host registration.

    If anyone with this exact “Connected / host running / acquisition still hangs” state tries WinBridge, please leave the result at zemeng5208/winbridge-recovery#4. ✅ fixed, 🟡 local inconsistencies repaired but timeout remained, and ❌ no change are all useful field results.

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 working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions