›_ Codex Issues
Codex Issues / #30227

Chrome plugin remains disconnected and @Chrome tool is not exposedThis blocks my main use case. I need the Chrome plugin to reliably control signed-in Chrome pages before each task, including reading page content, clicking, filtering, and taking screenshots. Falling back to Windows window-title reading is not sufficient.blocks my main use case”，让

Open 💬 3 comments Opened Jun 26, 2026 by gqiqiang750-spec
💡 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.623.31921 Microsoft Store package: OpenAI.Codex_26.623.4041.0_x64

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 x64 Microsoft Windows NT 10.0.26200.0

What issue are you seeing?

The Codex Chrome plugin remains disconnected and @Chrome does not expose the dedicated Chrome tab/control interface.

Feedback ID:
no-active-thread-019f0362-7838-7292-84b8-a482828d0593

Chrome extension:

  • Codex Chrome Extension v1.1.5 is installed and enabled.
  • It is installed in the Chrome Default profile.
  • The Chrome extension popup still shows Disconnected.

Native host checks:

  • Native host manifest exists.
  • Registry key exists:

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

  • The manifest points to a valid extension-host.exe.
  • check-native-host-manifest reports correct: true.
  • check-extension-installed reports installed: true and enabled: true.

What happens:
When I run:
@Chrome 读取当前 Chrome 页面标题

Codex does not use the Chrome tab/control interface. It falls back to reading the Windows Chrome window title and says it did not get the dedicated Chrome tab interface.

I already tried:

  • Restarted Chrome and Codex.
  • Restarted the computer.
  • Removed and re-added the Chrome plugin in Codex.
  • Reinstalled Codex from Microsoft Store.
  • Reinstalled/moved Codex to C drive.
  • Started a new Codex thread and tested @Chrome again.

Expected behavior:
@Chrome should connect to the Codex Chrome Extension and read the current Chrome tab/page title directly.

What steps can reproduce the bug?

Feedback ID: 019f0342-9819-7473-ba2c-a4fc426b429a

What is the expected behavior?

_No response_

Additional information

<img width="914" height="505" alt="Image" src="https://github.com/user-attachments/assets/b08328ac-fbd9-4113-93f4-2a78bf4fa666" />

<img width="778" height="450" alt="Image" src="https://github.com/user-attachments/assets/e7aea57b-8430-4149-97a2-be2ac21aad85" />

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.

  • #28880
  • #29389
  • #29999
  • #30155

Powered by Codex Action

gqiqiang750-spec · 2 months ago

Additional finding:

After reinstalling Codex and restarting/logging out/in multiple times, the issue still persists.

Local checks show:

  • Chrome extension v1.1.5 is installed and enabled.
  • Native messaging host manifest exists and passes validation.
  • Registry path for com.openai.codexextension is correct.
  • Chrome plugin is enabled in Codex.
  • However, Codex rewrites ~/.codex/config.toml after startup and sets:

[features]
js_repl = false

Because of this, the dedicated Chrome/browser control tools are not exposed to the agent. @Chrome falls back to reading the Windows Chrome window title instead of using the Chrome tab interface.

This does not look like a Chrome extension installation issue anymore. It looks like the Codex app/account/tool exposure layer is disabling or failing to expose node_repl / browser-use / Chrome tools.

zemeng5208 · 12 days ago

I maintain WinBridge Recovery, an independent Windows recovery/diagnostic tool for Codex Desktop local plugin/runtime state.

The combination here is useful: the Chrome extension is installed/enabled, the Native Host manifest and HKCU registration validate, reinstall/restart does not help, and the app later rewrites config.toml with js_repl = false. That makes it important to separate two very different failure classes instead of repeatedly reinstalling Chrome.

WinBridge can verify the Windows local-state side: active CODEX_HOME, current Store/AppX package generation, bundled marketplace, Browser/Chrome/Computer Use cache versions and latest, node_repl / CODEX_CLI_PATH consistency, Native Host manifest/registry/v2 metadata, and the local runtime/app-server paths. If those user-owned layers are stale or version-split, it can reconstruct them from the already installed official package with verification, backup and rollback.

However, if Desktop is intentionally rewriting js_repl = false after startup because of a product/entitlement/session provisioning decision, WinBridge should not override that as a security/feature-gate bypass. In that case a clean local-state result is useful evidence that the remaining problem belongs in the upstream tool-exposure layer.

So this issue is a good A/B case: diagnose/repair local drift first; if the app still rewrites the feature state and @Chrome remains unavailable, stop local repair and report that exact behavior upstream. If anyone tests WinBridge on this symptom, outcome reports (worked / partial / did not work) are welcome here: https://github.com/zemeng5208/winbridge-recovery/issues/4