Chrome plugin mention is selectable but chrome@openai-bundled is not exposed in active tools

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

• #21598
• #21741

Powered by Codex Action

This likely overlaps with #21598.

The additional symptom in this issue is that the UI mention picker can insert [@chrome](plugin://chrome@openai-bundled), but a fresh chat still does not receive chrome@openai-bundled in active tools. The runtime reports only Browser / in-app browser, so @chrome requests can fall back to the in-app browser even though the Chrome mention is selectable.

If maintainers prefer, this can be closed as a duplicate of #21598.

I’m seeing the same issue on Windows 11.

Chrome for Codex appears installed/enabled/connected everywhere in the UI, but the active session does not receive chrome@openai-bundled as a callable tool.

Evidence:

• Chrome extension v1.1.4 shows Connected.
• Codex Plugins → Chrome page is available.
• “Try in chat” inserts the Chrome mention.
• config.toml contains:

[plugins."chrome@openai-bundled"]
enabled = true

• In the thread, Codex says:

“I can’t use a Chrome plug-in in this session because chrome@openai-bundled is not available in the active plugin list.”

• It falls back to browser-use / in-app browser.

Correlation ID from in-app feedback:
7d7e1339-3b28-47c8-b4f8-401ff33ab5c5

This looks like UI/config/plugin install succeeds, but the fresh chat runtime/tool list is missing chrome@openai-bundled.

I can reproduce a very similar issue on Windows.

Uploaded / relevant thread id:

019e0fbb-b450-7213-9922-a241a4ddb94e

In that fresh thread, I explicitly used:

[@chrome](plugin://chrome@openai-bundled) 为我使用这个插件打开一个页面并搜索一加一等于几

The assistant did not follow the Chrome skill path. It replied that:

chrome@openai-bundled 这个插件当前没有可调用入口；可用的浏览器插件连接也超时了。所以我改用系统默认浏览器打开了 Bing 搜索页。

So the explicit @chrome mention was treated as unavailable / not callable, and the task fell back to a non-Chrome route.

In the same thread, after I manually provided the Chrome workaround instructions, the Chrome backend did work:

{
  "selectedBrowser": {
    "name": "Chrome",
    "type": "extension"
  }
}

and the page opened successfully through the Chrome extension backend.

This suggests the Chrome backend can be available, but the fresh thread did not reliably route the explicit plugin://chrome@openai-bundled mention to the Chrome skill/runtime.

HUGE Thanks @JMC2002 your backend-selection workaround helped confirm what’s happening on my system.

Update / confirmation:

I can visually confirm that the real Chrome tab opened on my machine. (TEMPORARILLY, See update below)

When I forced Codex to list browser backends and select the backend with type "extension" / name "Chrome", it opened https://www.backyardchickens.com/ in an actual Chrome tab.

So in my case:

• Chrome extension backend works
• A real Chrome tab opens successfully
• The issue is not basic Chrome extension connectivity
• The remaining problem is that normal @Chrome / Chrome mention behavior does not reliably route to the Chrome extension backend unless I explicitly force backend selection

• UPDATE:

Follow-up update:

The backend-selection workaround worked temporarily, but it has now become unreliable again, even using GPT-5.5 high.

Earlier, forcing Codex to list browser backends and select Chrome/type extension worked. I visually confirmed it opened a real Chrome tab.

However, later runs using the same style of prompt stopped behaving consistently. Codex started trying other routes again, including:

• installed desktop Chrome
• Playwright
• temporary Chrome profile
• debugging-port style automation

That is not the desired path. The desired path is the already-connected Codex Chrome extension backend.

So my current read is:

• The Chrome extension itself works.
• The Chrome backend can sometimes be reached manually.
• But normal @Chrome / Chrome mention behavior and even explicit backend-selection prompts are not reliable across sessions/runs.
• Codex may still fall back to in-app browser or lower-level browser automation instead of consistently using the Chrome extension backend.

Prior correlation ID:
7d7e1339-3b28-47c8-b4f8-401ff33ab5c5

Additional confirmation from Windows x64 on Codex Desktop 26.513.3673.0.

I can reproduce the same split between local Chrome connectivity and fresh-chat tool exposure:

• Codex settings and the Chrome extension both show connected.
• ~/.codex/config.toml has chrome@openai-bundled enabled.
• [marketplaces.openai-bundled].source points at the current WindowsApps package for OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0.
• ~/.codex/plugins/cache/openai-bundled/chrome is a junction to the current bundled plugins/chrome directory.
• The Chrome native messaging manifest exists and points to ~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/chrome/extension-host/windows/x64/extension-host.exe.
• extension-host.exe processes are running with chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ in their command line.
• However, fresh Codex sessions still do not receive any callable Chrome/browser tool. Searching the active tool surface for chrome / browser only exposes unrelated app tools, and the assistant reports that chrome@openai-bundled is not available in the active tool list.
• The latest local ~/.codex/cache/codex_apps_tools/*.json cache also contains no chrome, browser, browser-use, openai-bundled, or node_repl entries.

This suggests the remaining failure is after local setup/native-host connectivity: the fresh chat runtime/tool injection step is not including chrome@openai-bundled, even though the UI and Chrome extension state both indicate the connection is ready.

Additional update:

I re-tested the explicit backend-selection workaround, and it is now consistently working for me again on Windows.

Prompt approach:

• Ask Codex to find and read the Chrome skill instructions
• Use agent.browsers.list()
• Select Chrome / type extension
• Do not use iab / in-app browser
• Do not use direct Chrome launch, standalone Playwright, Puppeteer, debugging ports, or temporary profiles

Result:

• Codex found and fully read the Chrome skill at:

C:\Users\user\.codex\plugins\cache\openai-bundled\chrome\0.1.7\skills\chrome\SKILL.md

• The first connection attempt hit a “not trusted” path check, then Codex switched to the bundled marketplace Chrome plugin path that the skill expects.
• It then saw:
• Chrome / type extension
• Codex In-app Browser / type iab
• It selected Chrome / extension
• It opened https://www.wikipedia.com in a real Chrome tab
• Final URL became https://www.wikipedia.org/
• Page title was “Wikipedia”
• It did not use iab / in-app browser

So the workaround is not permanently broken on my side. It appears to work when the Chrome skill and Chrome extension backend are successfully exposed in that session.

Cross-reference from #24969 because this appears to be the same class of issue: UI/config/extension state suggests Chrome should exist, but the active runtime does not expose it.

On Windows Microsoft Store Codex 26.519.11010.0:

• Settings → Computer use shows Google Chrome disabled: Disabled by your organization or unavailable in your region.
• Chrome extension is installed/enabled and native host manifest is correct.
• Extension local state shows native host connected.
• codex features list shows computer_use, browser_use_external, browser_use, in_app_browser, and plugins enabled.
• Normal browser runtime still lists only Codex In-app Browser / iab; agent.browsers.get("extension") is unavailable.

This looks like the Chrome/Computer Use plugin/backend is being filtered out by entitlement/region/rollout or active tool provisioning, not a missing extension/native host. If this is expected for Windows or UK/EU users, the UI/docs/release notes should say so clearly.

Closing as a duplicate of #21598.