[Bug]: Native popups opened with window features (pop-out players, OAuth) from desktop preview tabs are invisible to agents #30384

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

Desktop app (macOS) with its local environment, so the agent's preview tab is rendered by the desktop.

1. Serve these two files locally (for example python3 -m http.server 8765):

   <!-- index.html -->
   <button id="popout" onclick="window.open('popup.html?kind=popout', 'player', 'width=520,height=360')">Pop-out player</button>
   <button id="auth" onclick="window.open('popup.html?kind=auth', 'auth', 'popup,width=420,height=520')">Sign in</button>

   <!-- popup.html -->
   <!doctype html><title>Popup</title><p>Popup loaded</p>

2. Agent: preview_open({ url: "http://127.0.0.1:8765/index.html", reuseExistingTab: false }) → tab A.
3. Agent: preview_act({ tabId: A, action: "click", selector: "#popout" }), then the same for #auth.
4. Agent: preview_status({ tabId: A }).
5. Agent: preview_evaluate({ tabId: A, expression: "window.open('', 'player').location.href" }).

Expected behavior

Each popup becomes a tab the agent owns, with window.opener intact, as popups from headless server tabs already do through adoptPopup. The agent can snapshot it, act in it, and see it close.

Actual behavior

• Step 3: a native window appears for each click.
• Step 4: tabs lists only A. Neither popup is addressable as a preview tab, so the agent has no snapshot, act, or close for it.
• Step 5 returns http://127.0.0.1:8765/popup.html?kind=popout: the popup is loaded and working. A same-origin popup can sometimes be scripted or closed indirectly through preview_evaluate on the opener, but that gives no normal tab tooling. Cross-origin restrictions prevent reading or interacting with the popup's DOM through the opener, although limited operations such as close() and postMessage() may remain available.

This can block any flow that continues in an HTTP(S) popup opened with window features, such as a content player's pop-out, a sign-in, payment or share window. The repro uses a synthetic player/sign-in page; I have not tested real OAuth providers.

HTTP(S) requests classified as foreground-tab or background-tab, without a POST body, follow the separate new-tab path. Ordinary target="_blank" links commonly take this path. Ownership of those tabs is #26250, which also notes the relay limitation; #29198 covers closing unclaimed tabs in general. This issue concerns native new-window popups. Related: #6561 (earlier OAuth popup blocking) and #13348 (open PR that parents native popups to the T3 window and disables FedCM for preview guests).

Root cause (main 12ec17c)

• previewWindowOpenAction returns "popup" for an HTTP(S) disposition: "new-window", and the guest's window-open handler allows a native BrowserWindow, kept native so OAuth keeps window.opener (Manager.ts#L447-L465, Manager.ts#L1540-L1544).
• The server drives desktop-rendered tabs over Playwright connectOverCDP through the desktop's CDP relay, which lists, attaches and announces only the tab's own page (CdpRelay.ts#L157-L186; its test is "announces only the tab's page, under its real target id"). The popup's webContents is never exposed.
• So page.on("popup") → adoptPopup (ServerBrowser.ts#L979-L980, ServerBrowser.ts#L1305) never runs for desktop-rendered tabs. This omission does not affect headless server tabs, where Playwright's own Chromium reports popups.

Suggested direction

Make native HTTP(S) popups discoverable and controllable through the preview tools, inheriting the opener's agent ownership while preserving browser popup semantics and desktop behavior. Exposing their targets through the CDP relay appears to let the existing adoptPopup path handle ownership; adopted native popups would also need to retain desktop-specific handling. The local candidate keeps the native windows; named-window reuse and full desktop integration still need verification.

I have a local candidate fix along these lines, described below, and can open a PR for it once the direction is triaged.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Nightly) 0.1.7-nightly.20261103.4106; source analysis on main 12ec17c

Environment

macOS 27.0 (arm64), desktop app with its local environment, Claude Code provider.

Logs or stack traces

# preview_status for tab A after both clicks (trimmed)
"tabs": [
  { "tabId": "tab_1_…", "url": "http://127.0.0.1:8765/index.html", "owner": "agent", "ownedByCaller": true }
]
# server trace for tab A shows DesktopBrowserChannel.awaitAttached / endpoint / pointer, so the tab is desktop-rendered

Workaround

A person can finish the flow in the native popup window. An agent can script a same-origin popup only indirectly, through preview_evaluate on the opener; it cannot read or act in a cross-origin popup's page.