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

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

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