codex - 💡(How to fix) Fix Windows: Chrome plugin can open Chrome/page but fails to establish usable browser-control session

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

26.506.3741.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?

Related feedback ID: 23f106f6-7247-42d8-92ab-d4f05ad7404c

Summary

On Windows, the Codex Chrome plugin can sometimes launch Chrome or open the requested page, but it does not establish a usable extension-backed browser-control session afterward.

This is not simply a page-load failure. The browser window/page may appear visually, but Codex cannot reliably connect to it, list tabs, read page state, type, click, or continue the requested browser task.

The extension and native messaging setup appear to be present and valid, but the official extension-backed runtime still times out around setupAtlasRuntime, agent.browsers.get("extension"), or browser.user.openTabs().

Environment

• OS: Windows 10 Home China
• Windows version: 2009
• OS build: 26200
• Architecture: x64
• Codex App package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Codex App version: 26.506.3741.0
• Chrome: Google Chrome Stable
• Chrome path: C:\Program Files\Google\Chrome\Application\chrome.exe
• Chrome version: 148.0.7778.168
• Chrome profile: %LOCALAPPDATA%\Google\Chrome\User Data\Default
• Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Chrome Extension version directory: 1.1.4_0
• Extension installed/enabled: yes
• Extension disabled: no
• Extension popup “Connected”: yes

Reproduction

1. Open Codex App on Windows.

2. Install/enable the official Codex Chrome plugin through the Codex App plugin flow.

3. Use Google Chrome Stable with the Default profile.

4. Confirm the Codex Chrome Extension is installed and enabled.

5. Run a minimal Chrome task through the official @Chrome path:

   @Chrome open https://www.google.com

6. Chrome or the target page may open.

7. Codex then fails to establish a usable browser-control session.

8. Follow-up operations such as listing tabs, reading page state, typing, clicking, or continuing the browser task time out or fail.

Expected behavior

After Chrome is launched and the extension/native messaging host are installed correctly, Codex should establish a usable extension-backed browser session.

Basic operations should work, including opening or listing tabs, navigating, reading page state, typing, clicking, and continuing the requested browser task. If the session cannot be established, Codex should return a clear actionable error instead of hanging until timeout.

Actual behavior

• Chrome/page launch may succeed visually.
• The extension-backed browser-control channel never becomes usable.
• setupAtlasRuntime, agent.browsers.get("extension"), and browser.user.openTabs() time out or hang.
• open-chrome-window.js may time out even though Chrome later appears to be running.
• Multiple extension-host.exe and native-messaging-related cmd.exe processes were observed after failed attempts.

Diagnostics

Native messaging registry key:

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

Registry default value:

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

Manifest path:

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

Manifest content, with user path redacted:

{
  "name": "com.openai.codexextension",
  "description": "Codex chrome native messaging host",
  "type": "stdio",
  "path": "%USERPROFILE%\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe",
  "allowed_origins": [
    "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"
  ]
}

Native host executable:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

Observed:

• extension-host.exe exists.
• File size: 562688 bytes.
• Native host was observed running through Chrome native messaging.
• Multiple extension-host.exe instances remained after failed attempts.
• Multiple native-messaging-related cmd.exe processes were also observed.

Example native host command line, with user path redacted:

"%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe" chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0

Example native-messaging-related cmd.exe command line, with user path redacted:

C:\Windows\system32\cmd.exe /d /s /c ""%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe" chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0" < \\.\pipe\chrome.nativeMessaging.in... > \\.\pipe\chrome.nativeMessaging.out...

Observed timeout/error keywords:

• setupAtlasRuntime
• agent.browsers.get("extension")
• browser.user.openTabs()
• js execution timed out; kernel reset, rerun your request
• tool call error: tool call failed for node_repl/js
• timed out awaiting tools/call after 120s
• command timed out after 34011 milliseconds

Observed timeouts:

• 120 seconds: first official extension-backed setup/navigation attempt.
• 30 seconds: lightweight browser.user.openTabs() retry.
• About 34 seconds: scripts/open-chrome-window.js; Chrome later appeared to be running.
• 60 seconds: final official extension-backed setup/navigation attempt.

Suspected failure area

The failure appears to be after installation/registration succeeds, in the extension-backed browser communication/control path.

Likely areas to inspect:

• Handshake between Codex App / browser-client runtime and the Chrome extension.
• Extension-backed browser session discovery after Chrome/page launch.
• Native messaging host lifecycle on Windows.
• Pipe communication between Chrome native messaging and extension-host.exe.
• Stale extension-host.exe or native-messaging cmd.exe process handling.
• Timeout/retry behavior when Chrome opens but no usable browser-control channel is established.

Notes

No unsupported workaround was used:

• No Playwright workaround.
• No CDP / remote debugging.
• No OS-level UI automation.
• No simulated clicks.
• No browser database access.
• No reading of Chrome cookies, local storage, passwords, history, or browser databases.

The task was left incomplete because the official Chrome plugin could at most launch Chrome/open a page in some attempts, but could not establish a usable browser-control session for real interaction afterward.

What steps can reproduce the bug?

1. Open Codex App on Windows.

2. Enable/install the official Codex Chrome plugin from the Codex App plugin flow.

3. Use Google Chrome Stable with the Default profile.

4. Confirm that the Codex Chrome Extension is installed and enabled in Chrome.

5. Run a very simple Chrome task through the official @Chrome path:

   @Chrome open https://www.google.com

6. In some attempts, Chrome or the target webpage may open successfully.

7. However, Codex does not establish a usable browser-control connection after that.

8. Any follow-up browser operation fails or hangs, including reading tabs, interacting with the page, typing, clicking, or continuing the requested task.

Important clarification

This is not simply “Chrome cannot be launched.” Chrome can sometimes be opened, and the webpage can sometimes be loaded. The actual failure is that Codex cannot connect to or control the extension-backed browser session after launch.

The browser window/page may exist visually, but Codex cannot reliably operate it.

Observed failing operations

The failure happens around the official extension-backed browser runtime, including:

• setupAtlasRuntime
• agent.browsers.get("extension")
• browser.user.openTabs()

The connection either times out or becomes unusable before Codex can perform real page interaction.

Observed behavior

• Chrome Stable is installed.
• The Codex Chrome Extension is installed and enabled.
• The native messaging registry key and manifest appear valid.
• extension-host.exe exists and can be observed running.
• Chrome or the target webpage may open.
• But Codex cannot continue operating the page.
• Listing tabs, controlling the page, typing, clicking, or completing a browser task times out or fails.

No Playwright workaround, CDP / remote debugging, OS-level UI automation, simulated clicks, or browser database access was used.

What is the expected behavior?

Expected behavior

The official Codex Chrome plugin should establish a usable browser-control session after Chrome is launched and the extension/native messaging host are installed correctly.

Expected behavior:

1. If Chrome is not running, the official helper should open Chrome with the selected profile.
2. Once Chrome is running, setupAtlasRuntime should complete successfully.
3. agent.browsers.get("extension") should return a usable extension-backed browser connection.
4. Basic browser operations should work, including:
   • listing open tabs
   • opening a new tab
   • navigating to a URL
   • reading page state
   • typing into input fields
   • clicking page elements
   • continuing the requested browser task
5. If the extension-backed browser-control session cannot be established, Codex should return a clear actionable error instead of hanging or timing out.

The expected behavior is not merely that Chrome opens. The plugin should provide a usable browser-control channel after Chrome/page launch.

Actual behavior

• Chrome or the requested page may open in some attempts.
• After that, Codex cannot establish or use the extension-backed browser-control session.
• Initial Chrome extension-backed connection attempts time out.
• browser.user.openTabs() also times out.
• open-chrome-window.js may time out even though Chrome later appears to be running.
• Final official extension-backed browser attempts still time out.
• The Chrome plugin never becomes usable for actual page interaction.
• Multiple extension-host.exe processes and native-messaging-related cmd.exe processes were observed after failed attempts.

Additional information

I did not use unsupported workarounds to control Chrome:

• No Playwright workaround.
• No CDP / remote debugging.
• No OS-level UI automation.
• No simulated clicks.
• No browser database access.
• No reading of Chrome cookies, local storage, passwords, history, or browser databases.

The browser task was left incomplete because the official Chrome plugin could at most launch Chrome/open a page in some attempts, but could not establish a usable browser-control session for real interaction afterward.