[ChatGPT Work Web][Windows] “Unable to take over the browser” blocks authentication

Surface

ChatGPT Work on the web, using the built-in cloud-browser Live View / takeover flow.

Platform

• Windows desktop
• Chrome 151
• Observed: August 18, 2026 (America/New_York)

Issue

The assistant can initialize and control the cloud browser, open pages, and see live tab state. When authentication requires the user to take over the browser, the Live View takeover fails every time.

The UI shows:

• Unable to take over the browser
• Please try again.
• You can't take over the browser right now. Please try again.

The failure persisted after:

• clicking Try again multiple times;
• opening a fresh browser tab/session for the target portal;
• removing the stale authentication tab;
• starting a completely new ChatGPT chat.

Steps to reproduce

1. In ChatGPT Work on the web, ask the agent to use its cloud browser for an authenticated portal workflow.
2. Let the agent open a portal that requires user credentials (Microsoft Power Automate and Netlify were the affected examples).
3. When the assistant reaches the sign-in page, use Live View and click the browser takeover control.
4. Observe two red Unable to take over the browser notifications and a black Live View panel saying takeover is unavailable.
5. Click Try again.
6. The same failure repeats. Starting a new chat does not recover it.

Actual behavior

The assistant-side browser connection remains alive and can navigate pages, but the user cannot take control to enter credentials. Because credentials must not be entered in chat or by the assistant, the authenticated workflow becomes impossible to continue.

Expected behavior

• The takeover control should reliably attach the user to the exact live browser tab.
• If the session is stale, the product should provide a working browser-session reset that preserves the chat/project state.
• The UI should expose a diagnostic/session identifier when takeover fails.
• Repeated retries caused by an internal takeover failure should not consume the user's paid usage/credits.

Impact

This is a hard blocker for real authenticated portal work. In this case it prevented a time-sensitive, staging-only deployment and acceptance workflow after extensive prior work. The recovery loop also consumed additional paid usage while failing for an internal product reason, creating significant user frustration and loss of trust.

Privacy

No credentials, account email, OAuth URL/state, project name, or customer data are included in this report.

Related

• #39071 describes a similar inability to foreground an OAuth browser preview in Codex Desktop, but this report is specifically ChatGPT Work on the web where an explicit Take over browser action displays an error.
• #25209 covers broader authenticated browser reliability concerns.

Start by reproducing the failure in ChatGPT Work on the web using the Live View takeover flow with an authenticated portal. Trace the browser-session takeover entry point and compare it with related issues #39071 and #25209. Done means users can attach to the exact live tab, recover stale sessions, and receive useful diagnostics without repeated failed retries consuming credits.