Skip to content

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

Open
Open
Codex Desktop: @Chrome extension is Connected but browser tasks fall back to chrome-devtools isolated profile on Windows#21868
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

Description

@xuchenghaowan
xuchenghaowan
opened on May 9, 2026

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:

  1. My real Chrome user profile:

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

  2. 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

  1. Enable the bundled Chrome plugin in Codex Desktop.
  2. Install the Codex Chrome extension in Google Chrome.
  3. Confirm the extension popup shows Connected.
  4. Make sure Chrome is running with the real user profile.
  5. Start a new Codex thread.
  6. Ask Codex to do a browser task using @Chrome, for example:
@Chrome open Zhihu
  1. 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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    mcpIssues related to the use of model context protocol (MCP) servers
    skillsIssues related to skills
    on May 9, 2026

  2. github-actions commented on May 9, 2026

    @github-actions
    github-actionsBot
    on May 9, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. xuchenghaowan commented on May 9, 2026

    @xuchenghaowan
    xuchenghaowan
    on May 9, 2026 – with ChatGPT Codex Connector
    Author

    I reviewed the potential duplicates suggested by the bot.

    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.

  4. mySebbe commented on May 12, 2026

    @mySebbe
    mySebbe
    on May 12, 2026

    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.

  5. kiluazen commented on May 16, 2026

    @kiluazen
    kiluazen
    on May 16, 2026

    @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.

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 workingmcpIssues related to the use of model context protocol (MCP) serversskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions