Codex Desktop: @Chrome extension is Connected but browser tasks fall back to chrome-devtools isolated profile on Windows

Open 💬 4 comments Opened May 9, 2026 by xuchenghaowan

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Description

On Windows, the Codex Chrome plugin appears fully installed and connected, but browser tasks that should use @Chrome still fall back to the isolated Chrome DevTools MCP browser profile instead of controlling my real Chrome profile/session.

The result is that authenticated state from my real Chrome profile is not available, even though the Codex Chrome extension shows Connected.

Environment

Codex Desktop on Windows
Google Chrome installed
Codex Chrome extension installed and enabled
Extension popup shows Connected
chrome@openai-bundled enabled in C:\Users\JSTB2021\.codex\config.toml

What I expected

When I start a fresh thread and use @Chrome, Codex should control my real Chrome profile and be able to access the logged-in browser session associated with that profile.

What actually happens

A fresh thread with @Chrome still ends up using an isolated browser profile instead of my real Chrome profile.

From local inspection, I can see two distinct Chrome environments:

My real Chrome user profile:

C:\Users\JSTB2021\AppData\Local\Google\Chrome\User Data\Default

The isolated browser automation profile that gets used instead:

C:\Users\JSTB2021\.cache\chrome-devtools-mcp\chrome-profile

This means browser actions do not inherit my real Chrome login state.

Verified locally

I verified all of the following before filing:

C:\Users\JSTB2021\.codex\config.toml contains:

[plugins."chrome@openai-bundled"]
enabled = true

The plugin package exists locally under bundled/cache paths.
The Chrome extension is installed, registered, and enabled.
The native host manifest is present and correct.
The Chrome extension popup explicitly shows Connected.

I also ran the plugin-provided checks locally and they passed:

check-extension-installed.js --json
installed: true
registered: true
enabled: true
check-native-host-manifest.js --json
correct: true

Reproduction steps

Enable the bundled Chrome plugin in Codex Desktop.
Install the Codex Chrome extension in Google Chrome.
Confirm the extension popup shows Connected.
Make sure Chrome is running with the real user profile.
Start a new Codex thread.
Ask Codex to do a browser task using @Chrome, for example:

@Chrome open Zhihu

Observe that the task does not use the real Chrome profile/session and instead falls back to an isolated browser profile path such as:

C:\Users\JSTB2021\.cache\chrome-devtools-mcp\chrome-profile

Why this seems like a bug

The installation/connection chain appears healthy, but the runtime behavior still routes browser work through the isolated Chrome DevTools MCP path instead of the real Chrome extension-backed browser session.

This makes @Chrome unusable for tasks that depend on existing cookies, logged-in sessions, or already-open tabs in the user's real Chrome profile.

Related observation

This feels similar in spirit to desktop/browser routing issues such as #16696, where the configured or expected browser bridge path is not the one that gets used at runtime.

Additional note

If helpful, I can provide:

process listings showing the isolated profile path in the launched Chrome processes
exact local verification output from the plugin check scripts
screenshots showing the extension popup in Connected state

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#21791
#21598

Powered by Codex Action

xuchenghaowan · 3 months ago

I reviewed the potential duplicates suggested by the bot.

#21791 looks related, because it also describes a mismatch where @chrome / chrome@openai-bundled is not actually available to the runtime and browser work falls back to a non-Chrome path.
#21598 seems less directly related, because that one appears focused on Norway/EU availability / plugin discovery.

I am keeping this issue open for now because this report includes an additional concrete symptom that I do not see clearly captured in those issues:

the extension is installed and shows Connected
local plugin/native-host checks pass
but the actual browser task falls back to an isolated Chrome DevTools MCP profile path:
C:\Users\JSTB2021\.cache\chrome-devtools-mcp\chrome-profile

So this may be the same broader routing/runtime class of issue, but with a more specific Windows/Desktop fallback-to-isolated-profile manifestation.

If maintainers believe this should be merged/closed as a duplicate of #21791, that makes sense to me. I mainly wanted to preserve the more specific reproduction details and the isolated-profile evidence.

mySebbe · 3 months ago

Additional Windows data point tying browser fallback routing to process growth.

Environment:

Codex Desktop: 26.506.3741.0
Windows app-server PID: 8536
Chrome fallback profile path observed:
  C:\Users\sebbe\Documents\Codex\2026-05-11\finde-plattformen-wo-man-geld-mit\controlled_chrome_profile
remote-debugging-port: 9444

Current process footprint after repeated Browser Use / fallback-style browser work:

controlled_chrome_profile / remote-debugging-port=9444:
  chrome.exe processes: 74
  working set: ~10.4 GB
  oldest process: 2026-05-12 02:19:30
  newest process: 2026-05-12 13:27:48
  parent groups: 32984:73, 30592:1

playwright_chromiumdev_profile temp profile:
  chrome.exe processes: 20
  working set: ~1.6 GB
  oldest process: 2026-05-12 01:42:55
  newest process: 2026-05-12 02:11:16

CodexFabChromeProfile / remote-debugging-port=9333:
  chrome.exe processes: 7
  working set: ~0.47 GB

This is separate from the node_repl.exe MCP-host accumulation I reported in #20883/#21984. The local node_repl cleanup reduced stale node_repl.exe, but browser fallback/controlled-profile Chrome processes still represent the largest active footprint.

The relevant connection to this issue: when the intended Browser Use / Node REPL path is unavailable or deferred, agents fall back to a separate Chrome DevTools/controlled profile. In this Windows run that fallback path did not stay bounded and grew into dozens of long-lived Chrome processes using multi-GB memory.

Related tool-injection data point: #19365 / #20417. Related process-lifecycle reports: #17832 / #20883 / #21984.

kiluazen · 3 months ago

@xuchenghaowan — your diagnostics are all green (extension Connected, native-host manifest correct, real Chrome profile present at User Data\Default), so this isn't a setup bug on your side — it's a Codex backend routing issue. The intended path is @Chrome → Codex's native-host bridge (com.openai.codexextension) → your real Chrome profile, but when the bridge can't bind to a live tab (Windows profile permissions, Chrome 147+ extension isolation changes, MDM-managed profiles, etc.) the backend silently falls back to the chrome-devtools-mcp isolated profile under .cache\chrome-devtools-mcp\chrome-profile. That silent fall-through is the load-bearing bug — a loud failure here would have made the diagnosis obvious.

Sibling-shaped sanity check while the team digs in: Chrome Relay (https://chrome-relay.kushalsm.com/) ships the same primitive standalone (MV3 extension + native messaging host) and intentionally fails closed — if the host can't bind to a live tab, the CLI errors instead of opening a fresh profile. So if chrome-relay tabs returns your real tabs on this same Windows box, the entire native-messaging plumbing on your machine is fine and the issue is purely in Codex's routing layer (which is what your diagnostics already suggest). If chrome-relay's bridge also fails to bind, that narrows it to a Chrome-side / Windows-side issue that no harness can fix without an OS-level workaround.

Not a Codex replacement — different harness, different scope. Just a way to bisect.