›_ Codex Issues
Codex Issues / #37072

[Windows] Chrome plugin installed but native host and mcp__node_repl__js are missing

Open 💬 3 comments Opened Aug 5, 2026 by yqxkAnson

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

26.730.8199.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

The Codex Windows app cannot control Chrome even though the Chrome plugin and ChatGPT Chrome extension are installed and enabled.

Expected behavior

A Chrome-enabled Codex task should receive mcp__node_repl__js and be able to list the existing Chrome tabs.

Actual behavior

Neither the original task nor a newly created task receives mcp__node_repl__js, so Chrome cannot be controlled.

Diagnostics

  • Chrome is running.
  • ChatGPT Chrome extension version: 1.2.27236.6274_0
  • Extension diagnostic for Chrome profiles Default and Profile 3 returns:
  • installed=true
  • registered=true
  • enabled=true
  • Native-host diagnostic returns:
  • exists=false
  • correct=false
  • Missing registry key:

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

  • Missing manifest:

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

I updated and restarted Codex, restarted Windows and Chrome, removed and reinstalled the Chrome plugin, reinstalled the Chrome extension, and tested again in a new task. The problem remains.

IDs

Feedback ID: 019fd14d-2f55-7631-89f0-942383373bee

Original task: 019fd00c-ee77-77d2-90cc-0cf6297eacc2

New test task: 019fd14d-2f55-7631-89f0-942383373bee

Related to #25361, which was closed after recovery on macOS. This is a new Windows reproduction on the later Desktop build 26.730.8199.0. Unlike #25361, the Windows native-host registry key and manifest are also missing.

What steps can reproduce the bug?

  1. Install and enable the Chrome plugin in Codex Desktop.
  2. Install and enable the ChatGPT Chrome extension in the active Chrome profile.
  3. Restart Codex Desktop and Chrome.
  4. Create a new local Codex task and attach @chrome.
  5. Ask Codex to list the currently open Chrome tabs.
  6. Observe that mcp__node_repl__js is unavailable and Chrome cannot be controlled.

What is the expected behavior?

The Chrome-enabled Codex task should receive mcp__node_repl__js, connect to the active Chrome profile, and list the currently open tabs without modifying any page.

Additional information

Related open Windows reports:

  • #32802 — the Chrome plugin is installed/enabled, but the native-host manifest and registry key are never created.
  • #31152 — the Chrome extension is enabled, but the Native Messaging Host remains missing after reinstall.

This report reproduces the same native-host absence on the later Desktop build 26.730.8199.0 and additionally confirms that both the original and a fresh local task lack mcp__node_repl__js.

View original on GitHub ↗

3 Comments

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop local plugin/bridge recovery: https://github.com/zemeng5208/winbridge-recovery

This 26.730 reproduction is a strong match for the Native Host consistency layer WinBridge checks. The Chrome extension itself is installed/enabled, but both the user-level Native Messaging manifest and the HKCU com.openai.codexextension registration are absent after the normal reinstall/restart flow. WinBridge treats plugin payload, cache/latest, Native Host manifest, Chrome/Edge registry pointers and chrome-native-hosts-v2.json as separate states rather than assuming “plugin installed” means the bridge lifecycle completed.

For a genuinely missing local manifest/registry/v2 state, v3.1.1 can back up the user-owned bridge state, reconcile it against the currently installed official Chrome plugin/runtime, and validate the resulting paths afterward. It does not modify WindowsApps, browser enterprise policy, or the packaged app.

Important boundary: this report also mentions mcp__node_repl__js not being attached. If the Native Host/cache/runtime becomes healthy but a fresh task still does not receive the trusted Node REPL/Chrome tool, that is an upstream tool-injection/runtime layer WinBridge cannot honestly claim to repair. The useful split is: repair the missing local bridge first, then distinguish any remaining upstream attachment failure.

xieq59612-cloud · 9 days ago

I can reproduce a very similar issue, but with one important difference: my native host registry and manifest are already correct.

Environment:

  • Windows
  • Codex app package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
  • Install path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0

In a fresh Codex task:

typeof nodeRepl.nativePipe

returns:

"undefined"

Diagnostics:

  • Chrome extension is installed and enabled.
  • Native host registry key exists:

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

  • Registry default value:

C:\Users\Administrator\AppData\Local\OpenAI\extension\com.openai.codexextension.json

  • Native host manifest check outside sandbox passes:

correct=true
registryMatchesManifestPath=true
hasExpectedOrigin=true

Tried:

  • Restarting Chrome and Codex
  • Creating a new Codex task
  • Deleting/regenerating:

C:\Users\Administrator\.codex\plugins\cache\openai-bundled

  • Reinstalling Codex

Result:
nodeRepl exists, but nodeRepl.nativePipe is still undefined, so Chrome Browser Use cannot connect.

<img width="1280" height="820" alt="Image" src="https://github.com/user-attachments/assets/32340712-92f4-4976-a897-fe498af5e8a1" />

ajrogersmd · 17 hours ago

Reproduced on Windows with Codex desktop app version 26.820.71523 and Chrome plugin bundle 26.820.71523.

A new confirmed-local task explicitly attached @Chrome and received the Chrome-control skill. The installed scripts/browser-client.mjs file was present, but the required mcp__node_repl__js capability was absent from both the active and deferred tool inventory.

The failure occurred before browser-runtime initialization, Chrome discovery, or extension communication. No approval dialog appeared, and no tabs or browser data were inspected.

Configuration and recovery already verified:

  • Chrome extension status in Settings > Computer use: Installed
  • Enable full CDP access: enabled
  • Approval, History, Downloads, and Uploads: Always ask
  • Codex and Chrome restarted after extension installation
  • Reproduced in a new local task
  • Chrome selected explicitly; no fallback browser used

Feedback was submitted from the affected session, but the feedback ID was not retained.