macOS: Chrome extension connected but @Chrome tool is not provisioned to desktop task

[ajermin]

What version of the ChatGPT desktop app are you using?

26.820.71523 (build 7226), installed from the official macOS DMG and verified with the OpenAI Developer ID signature.

Platform

macOS, Apple Silicon (arm64)

Chrome environment

• Google Chrome 151.0.7922.174
• Official ChatGPT extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Extension version: 1.2.27268.51612
• Extension enabled in the active Default profile
• Site access set to all websites
• Side chat loads successfully
• Native Messaging manifest is present and points to the signed desktop-app host

Problem

The extension is installed and appears connected, but @Chrome cannot be used from the desktop task. Earlier attempts repeatedly failed with:

• No ChatGPT browser route is available for browser session 01a041f8-16e0-77b2-9ee8-1b119dc82fee
• browser use route window missing
• route window is not live
• EPIPE

After updating the desktop app to 26.820.71523, startup logs show that the internal browser route is captured successfully and the browser runtime paths are valid, but the existing task still does not receive the node_repl js / Chrome control interface, so it cannot list or read Chrome tabs.

This looks like a browser tool-provisioning or per-thread session-registration issue rather than an extension permission problem.

Troubleshooting already completed

• Restarted Chrome and ChatGPT in multiple orders
• Reinstalled the Chrome extension
• Confirmed the correct active Chrome profile
• Confirmed all-sites permission and Computer Use approval
• Reinstalled ChatGPT from the latest official notarized DMG
• Verified app and extension versions
• Verified Native Messaging manifest and signed host
• Confirmed that starting/restarting the internal browser route no longer produces the old route-window errors
• Checked VPN/proxy routing: ChatGPT uses the configured local Clash proxy; chatgpt.com, ab.chatgpt.com, and ws.chatgpt.com have active successful connections and WebSocket traffic. Localhost/Unix-socket communication is excluded from the proxy.

Expected behavior

A task that selects @Chrome should receive the Chrome browser control tool and be able to list/read the current tabs.

Diagnostic upload

Feedback and diagnostics were uploaded through /feedback.

Uploaded feedback thread: 01a0424f-0755-7f43-95e3-90a3944d840a

Please confirm whether this is a known regression in desktop browser tool provisioning/session registration and provide a fixed build or supported recovery procedure.

[github-actions]

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

• Codex Browser error report #40419
• [macOS][Chrome extension][regression] Browser controls no longer working #39972

Powered by Codex Action

[carstenvie]

Additional Windows reproduction (2026-08-30):

• The official Codex/ChatGPT Chrome side panel is open and the task was explicitly invoked with @Chrome.
• Codex can see the selected Chrome tab and successfully retrieve its text through the Chrome tab-context capability.
• The same task is not provisioned with the interactive Chrome browser-control route, so it cannot click or type in that already-visible tab.
• Updating/reinstalling the Chrome extension and restarting Chrome did not restore interactive control in the existing task.
• The target was a private LAN web application; its address and page contents are intentionally omitted.

Expected: a Codex task explicitly using @Chrome should receive interactive Chrome control for the selected tab, not only read-only tab context.

This appears consistent with the per-thread browser tool-provisioning/session-registration failure described in this issue, now reproduced on Windows as well.

[Kenawanewan]

Additional Windows reproduction from ChatGPT Work (2026-08-30):

• The user had a signed-in Google Ads tab visibly open in regular Chrome and explicitly asked the Work task to inspect it.
• The browser runtime identified Chrome/CDP, but browser.user.openTabs() returned an empty list; browser.tabs.list() exposed only a separate about:blank tab.
• A user screenshot taken at the same time confirmed that the real Chrome profile was signed in and the requested Google Ads campaign tab was open and usable.
• The fallback secure sign-in flow did not repair the route: the auth handoff ended with a closed transport, and the separate browser later displayed 502 Bad Gateway with [Errno 111] Connection refused on accounts.google.com/ServiceLogin.
• Manual handoff therefore opened the isolated browser, not the user's already-authenticated Chrome session.
• The user rebooted the PC/app three times. This is the second occurrence of a serious Work continuity/browser failure.

Expected: when @Chrome/Chrome control is requested, the task should receive the user's live Chrome tabs and authenticated profile. It should not silently fall back to an isolated cloud tab while reporting Chrome/CDP as the selected browser.

Private Google account and Ads account identifiers are intentionally omitted. Screenshots are available if maintainers need them through a private diagnostics channel.