[ChatGPT Work] Cloud Browser can surface another parallel chat’s tab

Summary

Two parallel ChatGPT Work chats under the same account appeared to use one shared Cloud Browser surface without explicit cross-chat ownership or isolation. One chat was working on Render while another attempted an authenticated Instagram task. After the Instagram handoff request timed out, opening Cloud Browser displayed the Render page from the other chat.

The observed behavior makes it difficult for the user and agent to determine which chat owns the visible browser state. Agent-side tab IDs and origin checks are useful safeguards, but do not provide account-level coordination or isolation.

Environment

• ChatGPT Work on the web
• Cloud Browser
• Windows desktop with Chrome
• Two parallel chats under one account
• Chat A: Render page and task
• Chat B: Instagram authentication task
• Observed: 29 August 2026

Steps that produced the incident

1. Keep a Cloud Browser task active in Chat A on a Render page.
2. In Chat B, start a Cloud Browser task for Instagram authentication.
3. Create a new Instagram tab in the browser selected for Chat B.
4. Submit credentials through the secure browser-authentication mechanism.
5. Observe that authentication returns submission_failed and Instagram remains on its login page without a visible credential error.
6. Request manual control for the exact Instagram tab.
7. Observe that the handoff request times out and the browser controller resets.
8. Open the Cloud Browser surface from the conversation.
9. Observe that the visible page is the Render page associated with Chat A rather than the Instagram task from Chat B.

Actual result

• The browser surface exposed state belonging to the parallel Render task.
• Chat B could not confirm whether its exact-tab handoff had succeeded.
• No account-level resource owner, conflict result, lease or isolated browser context was visible to the agent.
• The agent had initially described a new tab as a “fresh session,” although isolation had not been established.

This was one observed occurrence. It demonstrates an assurance gap but does not establish the product’s internal implementation or full reproducibility.

Expected result

The product should provide one of the following guarantees:

1. an isolated browser context/profile for each chat or browser task; or
2. explicit account-level coordination that leases shared browser resources to one task and routes handoff to the exact owned tab.

If neither guarantee can be established, authenticated or sensitive browser actions should fail closed with a specific resource-conflict result.

User impact

• The user cannot confidently associate the visible Cloud Browser tab with the requesting chat.
• Parallel browser work may interfere with task continuity.
• Authentication and other sensitive workflows lose clear ownership and assurance.
• Controller resets can leave task and handoff state unknown.
• The user must otherwise coordinate parallel chats manually, which should be a product responsibility.

Security assessment

• Instagram credentials were collected through the secure authentication mechanism bound to the https://www.instagram.com origin.
• There is no evidence that credentials were exposed to the model, entered into Render or transmitted to Render.
• Instagram authentication was not confirmed.
• This is not presented as a confirmed credential disclosure.
• It is a coordination and safety-control gap that creates ambiguity during sensitive workflows.

Requested product behavior

• Give each browser task an account-scoped owner and expiring lease.
• Bind ownership to the conversation, browser context, tab and expected origin.
• Use fencing tokens so stale controllers cannot act after reset or lease replacement.
• Route manual handoff to the exact leased tab.
• Preserve or safely invalidate ownership across controller resets.
• Surface cross-chat conflicts and serialize incompatible operations automatically.
• Distinguish clearly between a new tab and a genuinely isolated session.
• Never expose credentials, authentication material or session cookies to agents or logs.

Acceptance criteria

• Two parallel chats cannot surface or control each other’s browser tabs unintentionally.
• Manual handoff always opens the tab owned by the requesting task.
• Conflicting access waits or returns a specific resource-conflict response.
• A stale controller cannot continue after its lease expires or is replaced.
• Sensitive actions fail closed when ownership, tab identity or origin is ambiguous.
• “Fresh session” is used only when an isolated browser context/profile exists.
• The account owner can inspect and terminate active browser leases.
• Automated tests cover parallel navigation, authentication, manual handoff and controller-reset races.

Diagnostic strings observed

• Browser authentication result: submission_failed
• Manual-handoff/controller result: js execution timed out; kernel reset, rerun your request

Related issues

• #20852 requests explicit sessions, leases and conflict handling for parallel Computer Use.
• #39950 reports Cloud Browser handoff freezes and the lack of a true browser-session reset.

This report is distinct because it records a browser page from one parallel chat surfacing when another chat’s exact-tab handoff failed.

Privacy

No credentials, cookies, authentication codes, account email, private repository links or screenshots are included.

Start by reviewing related issues #20852 and #39950, then trace the flows associated with submission_failed and js execution timed out; kernel reset, rerun your request. Done means parallel chats cannot surface or control one another’s tabs, ownership conflicts fail safely, stale controllers are fenced out, and the listed parallel-operation and reset-race cases are covered by tests.