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

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.