fix(server): agent preview tabs follow the desktop page when it mounts late

[Jreevo]

Fixes #17334

Problem

A server preview tab decides once, in createTab, whether to drive the desktop's page. It waits DESKTOP_ATTACH_TIMEOUT (10s) for the desktop to attach. If the Browser panel isn't showing that thread in time, the tab runs headless, and for an agent-owned tab that means an isolated context. When the user later opens the panel, the desktop mounts its own <webview> for the same tab id and sends attached. Nothing in ServerBrowser listens for that, so the tab never switches over:

• The user sees the desktop page with their profile, which in the report was a signed-in RevenueCat dashboard.
• The agent keeps driving the headless page with empty storage, which showed a login page and 403s. preview_status reports visible: false.

Both show the same tab id and URL. Screenshots and tool output are in the issue.

Fix

• DesktopBrowserChannel exposes an attached stream next to detached.
• ServerBrowser subscribes to it. When the desktop attaches a tab that is running headless, including one still being created when the attach arrives, it drops the headless page and reconnects through findTab. createTab then sees the tab attached and connects to the desktop's page. The preview session, tab id, and automation owner are unchanged.
• dropTab takes a handOff flag, so streaming viewers of the dropped headless page get reconnect instead of gone. This matches the existing detach path.

Agent state in the old isolated context is discarded. Its only effect was the split this PR removes.

Verification

• New test an agent tab that started headless moves to the desktop's page once it mounts in apps/server/src/preview/ServerBrowser.test.ts. An agent opens a tab with no desktop attached (headless), then the fake desktop emits attached. The test asserts that viewers get reconnect, the server connects to the desktop endpoint, the headless context closes, and the agent still reaches the same tabId without a new headless context.
  • Fails on main: it times out waiting for the desktop connection.
  • Passes with the fix.
• vp test run src/preview/ServerBrowser.test.ts passes (24/24), as do the DesktopBrowserChannel tests.
• vp run typecheck in apps/server exits 0. vp lint and vp fmt on the changed files are clean.
• Not verified: a manual repro in a dev build of the desktop app. The reported failure came from Nightly 0.0.46-nightly.20261008.2833 on macOS.

Surfaces: server only. Web and desktop already render the tab natively. This change makes the server's automation follow that page. Mobile, web-only, and remote clients don't attach desktop pages, so the new stream is empty for them.

Model/harness: Claude Opus 5.5 (claude-opus-5-5) via Claude Code in T3 Code.

🤖 Generated with Claude Code

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Closing as superseded. #17334 was closed as a duplicate of #16901, so this PR no longer has an open target. If the fix still applies to the canonical issue, please open a new PR that references #16901.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The fix is narrowly scoped and tested, but it changes late-attached agents from isolated browser storage to the user's desktop page and existing sign-in state. That authentication-sensitive session handoff warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}