Skip to content

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

Closed as duplicate
Closed as duplicate
Chrome plugin mention is selectable but chrome@openai-bundled is not exposed in active tools#21791
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingskillsIssues related to skills

Description

@Stef9332
Stef9332
opened on May 8, 2026

Summary

The Codex app lets me insert/tag [@chrome](plugin://chrome@openai-bundled), but fresh chats do not receive chrome@openai-bundled as an active callable tool.

The UI and runtime disagree:

  • UI: chrome@openai-bundled can be selected/mentioned.
  • Runtime: the model reports that the Chrome tool is not available in active tools.
  • Result: requests tagged with @chrome either fail or fall back to Browser / in-app browser.

Environment

  • Platform: Windows x64
  • App: Codex desktop app
  • Plugins enabled in ~/.codex/config.toml:
[plugins."chrome@openai-bundled"]
enabled = true

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

Local plugin files exist at:

~/.codex/plugins/cache/openai-bundled/chrome/0.1.7

Reproduction

  1. Start a fresh Codex chat.
  2. Insert/select the Chrome plugin mention from the UI: [@chrome](plugin://chrome@openai-bundled).
  3. Ask the agent not to use Browser/in-app browser and to report which browser tools are actually active.

Prompt used:

Use only [@chrome](plugin://chrome@openai-bundled). If chrome is not actually available in active tools, do not use Browser/in-app browser. Tell me which browser tools you see.

Observed behavior

The model replies that chrome@openai-bundled is not present in active tools and that only Browser / browser-use / in-app browser is available.

In a separate attempt, asking [@chrome](plugin://chrome@openai-bundled) ajde idi na google.com caused the agent to use the in-app Browser plugin instead. When asked afterward, it confirmed it used Browser / in-app browser, not Chrome.

Expected behavior

If [@chrome](plugin://chrome@openai-bundled) can be selected in the UI and the Chrome extension is connected, the Chrome tool should be exposed to the model runtime.

If the Chrome tool cannot be exposed, the UI should not allow selecting the mention or should show a clear unavailable state before sending.

Additional diagnostics

The Chrome/extension backend can be reached manually from an existing diagnostic thread via the bundled chrome browser-client. In that diagnostic thread, the backend could list user tabs and open https://example.com successfully.

This suggests the browser backend itself can work, but new chats are not receiving chrome@openai-bundled in their active tool set.

Related issues that look similar in class:

Impact

This makes @chrome unreliable: the UI allows selecting it, but the runtime may silently lack the actual Chrome tool, causing accidental fallback to the in-app browser or failed Chrome-specific workflows.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    skillsIssues related to skills
    browser
    on May 8, 2026

  2. github-actions commented on May 8, 2026

    @github-actions
    github-actionsbot
    on May 8, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Stef9332 commented on May 8, 2026

    @Stef9332
    Stef9332
    on May 8, 2026 – with ChatGPT Codex Connector
    Author

    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.

  4. quiet-cedar-482 commented on May 8, 2026

    @quiet-cedar-482
    quiet-cedar-482
    on May 8, 2026

    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.

  5. JMC2002 commented on May 10, 2026

    @JMC2002
    JMC2002
    on May 10, 2026

    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.

  6. quiet-cedar-482 commented on May 10, 2026

    @quiet-cedar-482
    quiet-cedar-482
    on May 10, 2026

    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

  7. AndyZHENG0715 commented on May 16, 2026

    @AndyZHENG0715
    AndyZHENG0715
    on May 16, 2026 – with ChatGPT Codex Connector

    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.

  8. quiet-cedar-482 commented on May 16, 2026

    @quiet-cedar-482
    quiet-cedar-482
    on May 16, 2026

    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.

  9. centry4sangchu commented on May 28, 2026

    @centry4sangchu
    centry4sangchu
    on May 28, 2026

    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.

  10. ax-openai commented on Jun 12, 2026

    @ax-openai
    ax-openai
    on Jun 12, 2026 – with ChatGPT Codex Connector

    Closing as a duplicate of #21598.

  11. ax-openai
    closed this as duplicateon Jun 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingskillsIssues related to skills

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions