Explicit @chrome mention routes to IAB instead of Chrome extension backend

[rodrigoantonioli]

Summary

In Codex Desktop on Windows, an explicit user mention of @chrome did not reliably route browser automation to the Chrome extension backend. The agent initially used the Codex In-app Browser (iab) path instead, which caused a false authentication failure on a site where the user's main Chrome session was already authenticated.

Manually listing browser backends later showed that the Chrome extension backend was present and working. Selecting the Chrome backend of type extension fixed the issue immediately.

Environment

• OS: Windows
• Codex Desktop package observed from running process path: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Relevant bundled plugin path used by the agent: openai-bundled/browser-use/0.1.0-alpha2
• Chrome extension backend was available and functional in the same thread
• In-app browser backend was also available

What happened

The user explicitly referenced the Chrome plugin:

[@chrome](plugin://chrome@openai-bundled)

The task was to open Outlook Web using the user's main Chrome browser session. The main Chrome session was already authenticated.

However, the agent followed the Browser skill bootstrap path and selected:

agent.browsers.get("iab")

That opened the Codex In-app Browser instead of the Chrome extension backend. Outlook redirected to Microsoft login there, so the agent incorrectly reported an authentication blocker.

After the user challenged this and provided evidence that @chrome worked in another chat, the agent listed available browser backends:

const browsers = await agent.browsers.list();

It returned both:

[
  { "name": "Chrome", "type": "extension" },
  { "name": "Codex In-app Browser", "type": "iab" }
]

Selecting the Chrome backend explicitly worked:

const chrome = browsers.find((b) => b.type === "extension" || b.name === "Chrome");
const browser = await agent.browsers.get(chrome.id);

The same Outlook URL then loaded authenticated in the user's main Chrome session.

Expected behavior

When the user explicitly mentions @chrome / plugin://chrome@openai-bundled, Codex should route browser automation to the Chrome extension backend automatically, or at minimum strongly prefer the Chrome backend over iab.

The agent should not default to agent.browsers.get("iab") in a Chrome-targeted request when the Chrome extension backend is available.

If both backends are available, the tool/skill guidance should make backend selection explicit and safe:

1. List available browser backends.
2. If the user asked for @chrome, select type === "extension" or name === "Chrome".
3. Use iab only as an explicit fallback.

Actual behavior

• The explicit @chrome request was handled through the generic Browser setup path.
• The setup path selected the in-app browser (iab).
• The in-app browser did not share the user's authenticated Chrome session.
• The agent reported an Outlook/Microsoft authentication blocker.
• Manual backend discovery showed that the Chrome extension was available and worked.

Impact

This is especially harmful for recurring automations that depend on the user's already-authenticated main Chrome session, such as SharePoint, Outlook Web, internal systems, or other enterprise apps.

The failure mode is misleading: it looks like the site is not authenticated, but the real issue is that Codex selected the wrong browser backend.

Related issue

This may be related to the broader Windows browser/plugin instability tracked in #21670, but this report is narrower: the Chrome extension backend is available and works; the bug is that explicit @chrome intent did not select it by default.

[github-actions]

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

• Codex Desktop: @Chrome extension is Connected but browser tasks fall back to chrome-devtools isolated profile on Windows #21868
• Chrome plugin mention is selectable but chrome@openai-bundled is not exposed in active tools #21791

Powered by Codex Action

[rodrigoantonioli]

Reviewed the bot-suggested potential duplicates:

• Codex Desktop: @Chrome extension is Connected but browser tasks fall back to chrome-devtools isolated profile on Windows #21868 is related, but not the same symptom. That report says @Chrome falls back to an isolated Chrome DevTools MCP profile (.cache\chrome-devtools-mcp\chrome-profile) instead of the real Chrome profile. In this issue, the available backends were Chrome/extension and Codex In-app Browser/iab; the initial automation selected iab, while manually selecting the existing Chrome/extension backend fixed the task immediately.

• Chrome plugin mention is selectable but chrome@openai-bundled is not exposed in active tools #21791 is closer, but still not identical. That report says the Chrome mention is selectable while chrome@openai-bundled is not exposed as an active callable tool in fresh chats. In this issue, the Chrome extension backend was visible through agent.browsers.list() and worked in the same thread; the failure was that explicit @chrome intent did not cause the agent/skill path to prefer that backend and instead used agent.browsers.get("iab") first.

So this appears to be in the same broader routing/tool-selection class, but the distinguishing detail here is: the Chrome extension backend was present and functional; selecting it manually fixed the problem. The bug is that explicit @chrome did not steer backend selection toward Chrome/extension.

[rodrigoantonioli]

Additional code/config pointers from the affected machine:

The local bundled skill files point to the likely routing boundary:

• browser-use/0.1.0-alpha2/skills/browser/SKILL.md explicitly instructs the agent to select IAB:

  • globalThis.browser = await agent.browsers.get("iab")
  • this appears at the bootstrap examples and API reference.

• chrome/0.1.7/skills/chrome/SKILL.md exists locally and explicitly says it should be used when the user mentions @chrome:

  • Use this skill when the user mentions @chrome.
  • its bootstrap selects the Chrome extension backend:
    • globalThis.browser = await agent.browsers.get("extension")

So the lower-level backend/client path is not the obvious failure: agent.browsers.get("extension") works when chosen manually. The likely failure point is the plugin/skill routing or skill exposure layer: the explicit [@chrome](plugin://chrome@openai-bundled) mention did not cause the Chrome skill to be loaded/preferred, so the generic Browser skill path was followed and selected iab.

Public repo search note: openai/codex exposes chrome@openai-bundled in codex-rs/core-plugins/src/lib.rs allowlist, but I did not find the bundled Chrome skill body itself in the public repo via GitHub code search. That part appears to be supplied through the bundled plugin cache rather than exposed as ordinary source in the repo.

[rodrigoantonioli]

One additional context detail: the affected thread was created by a recurring automation, not started manually by the user. The user observed that manually-created chats appear to go through a visible workspace/plugin initialization phase before browser work, while this automation-created thread was already open with context loaded.

This may be relevant if plugin/skill routing differs between automation-started threads and manually-started chats. I do not have proof this is causal, but it matches the symptom: the Chrome extension backend existed and worked once manually selected, but the explicit @chrome mention did not initially load/prefer the Chrome skill.