Repository navigation
Explicit @chrome mention routes to IAB instead of Chrome extension backend #21876
Description
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:
- List available browser backends.
- If the user asked for
@chrome, selecttype === "extension"orname === "Chrome". - Use
iabonly as an explicit fallback.
Actual behavior
- The explicit
@chromerequest 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.
Activity
github-actions commentedon May 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
rodrigoantonioli commentedon May 9, 2026
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
@Chromefalls 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 wereChrome/extensionandCodex In-app Browser/iab; the initial automation selectediab, while manually selecting the existingChrome/extensionbackend 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-bundledis not exposed as an active callable tool in fresh chats. In this issue, the Chrome extension backend was visible throughagent.browsers.list()and worked in the same thread; the failure was that explicit@chromeintent did not cause the agent/skill path to prefer that backend and instead usedagent.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
@chromedid not steer backend selection towardChrome/extension.rodrigoantonioli commentedon May 9, 2026
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.mdexplicitly instructs the agent to select IAB:globalThis.browser = await agent.browsers.get("iab")chrome/0.1.7/skills/chrome/SKILL.mdexists locally and explicitly says it should be used when the user mentions@chrome:Use this skill when the user mentions @chrome.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 selectediab.Public repo search note:
openai/codexexposeschrome@openai-bundledincodex-rs/core-plugins/src/lib.rsallowlist, 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 commentedon May 9, 2026
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
@chromemention did not initially load/prefer the Chrome skill.