[Bug]: Desktop webview that attaches after the 10-second wait leaves the agent on the headless page with no signal #22882

Follow-up to #16901, as @t3dotgg asked in this comment. #19919 fixed the main case. This issue covers only the part that is still open: a desktop webview that attaches after the 10-second wait.

Before submitting

• I searched existing issues and did not find a duplicate. ([Bug]: Agent and browser panel show two different browser pages for the same browser tab #16901 and [Bug]: Agent drives a signed-out headless page while the Browser panel shows the user's signed-in page for the same tab #17334 are closed and cover the main case.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

I did not reproduce this timing on a real machine. The steps come from the code at 448b8a9186 and from the closing comment on #16901.

1. Run the desktop app with its local server. Sign in to a site in the Browser panel.
2. Make the desktop webview attach late. For example: the host is busy, the thread is not on screen, or a remote client is connected while the host panel does not show the thread (see the observation from @LeighAtkins in [Bug]: Agent and browser panel show two different browser pages for the same browser tab #16901).
3. From an agent, call preview_open for the signed-in site.
4. The server waits for the desktop page with awaitAttached(..., DESKTOP_ATTACH_TIMEOUT). DESKTOP_ATTACH_TIMEOUT is "10 seconds" (ServerBrowser.ts#L96, #L685-L693).
5. After the timeout, createTab builds the tab in the headless server browser (#L717-L730).
6. The desktop webview attaches a few seconds later.

Expected behavior

One of these:

• The server swaps the tab to the desktop page when the late attach arrives, or
• The tool results tell the agent that the tab runs in the headless fallback, so the agent can open a fresh tab instead of asking the user to sign in again.

Actual behavior

• The late attach is ignored. The desktopChannel.attached handler returns early when a tab with that key already exists (#L2476-L2488). The headless tab from step 5 already exists, so no swap happens.
• The agent keeps driving the headless page, which has its own cookie store (~/.t3/userdata/server-browser/profiles/default) and no panel logins. The panel shows the desktop page. This is the split from [Bug]: Agent and browser panel show two different browser pages for the same browser tab #16901.
• No client signal shows the state. preview_open and preview_status report profileId: "default", and t3_preview_list reports runtime: "server" in both cases. On 0.1.1-nightly.20261019.3348 the only hint was a viewport field in the preview_open result, and that hint is not documented.

Impact

Minor bug or occasional failure. It occurs only when the attach takes longer than 10 seconds. When it occurs, the agent tells the user that their logins expired and asks them to sign in again, which does not help.

Version or commit

Code read at main 448b8a9186. Installed build: T3 Code Nightly 0.1.2-nightly.20261021.3457 (e64766c56ac6).

Environment

macOS 27.2 (Apple silicon), desktop app with its local server, Claude Code thread. On this setup with the thread on screen the attach was fast and the agent tab used the desktop partition (test results), so I could not trigger the late path here.

Workaround

Call preview_open again with reuseExistingTab: false and open: true while the thread is on screen. The new tab usually attaches to the desktop webview.

Possible directions

• In the attached handler, replace an existing headless tab for the same key with the desktop page when no agent action is in flight.
• Add a field to preview_open, preview_status and t3_preview_list that shows where the tab renders (desktop webview or headless server browser).