[Bug]: Agent can list but not drive the user's browser-panel tab on the native Windows local server; agent tabs don't share its logins #22612

Before submitting

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

Area

apps/server

Summary

On native Windows with the desktop-launched local server (no WSL, no remote environment), the agent can list the user's open browser-panel tab with t3_preview_list, but it can't snapshot, read or attach to it. Every tab the agent opens instead is a separate runtime: "server" tab that doesn't share the user's logins, even though both report profileId: "default".

In practice the user has a signed-in site open in the thread's browser and asks the agent to read it. The agent keeps telling them to log in, because every page it can reach shows the login screen. We went round that loop five times before finding the cause.

Related: #19718 is the explicit-tabId fallback part. It is fixed by #19737 but not in stable v0.1.0, so it still reproduces here. That report was a WSL server, where driving a desktop tab is out of scope by design (#15328). This one is the desktop app's own local primary server on the same Windows machine. As I read #15328 ("the desktop app renders its own server's tabs natively in a <webview>, but the server still drives them"), the user's tab should be a server tab the agent can drive, so I think this is a separate bug.

Steps to reproduce

1. On Windows, run the T3 Code desktop app (v0.1.0) normally. The server is spawned by the desktop app, bin.mjs --bootstrap-fd 3, with parent process T3 Code (Beta).exe.
2. In a thread (Claude Code provider), open the browser panel and sign in to any site that needs a login. Leave the tab open on a signed-in page.
3. Ask the agent to read the page. It calls:
   • t3_preview_list(): lists the user's tab (tab_4) with the correct URL and title, profileId: "default", and no runtime field.
   • preview_status(): available: false, tabId: null, and the tab list is empty.
   • preview_snapshot({ tabId: "tab_4" }): PreviewAutomationTabNotFoundError: Preview tab tab_4 was not found for snapshot. Omit tabId to use the current tab, or call preview_open.
   • preview_open({ tabId: "tab_4" }): succeeds but returns a new blank tab tab_7_<serverEpoch> (the [Bug]: preview_open ignores an explicit desktop tabId and creates a new server tab #19718 behaviour).
   • preview_navigate on that agent tab to the same URL lands on the site's login page.
4. t3_preview_list() now shows both tabs: tab_4 (no runtime) and tab_7_… (runtime: "server").

Expected behavior

• On the desktop app's own local server, a tab the user opens in the thread's browser panel can be driven by the agent tools, as the tool descriptions say: "including a tab the user opened (see preview_status tabs)".
• preview_status().tabs includes every tab t3_preview_list returns for the thread. If one can't be automated, it should be listed with a reason.
• profileId: "default" means the same cookie store for user tabs and agent tabs. If they're different stores, the profile id shouldn't be shared.
• If a listed tab can't be driven, the error says so ("tab_4 is hosted on the desktop runtime and can't be automated from this server"), instead of "not found" plus a recovery hint that leads to the silent new-tab fallback.

Actual behavior

• The user's tab has no runtime field and is invisible to every automation tool except t3_preview_list.
• The agent's tabs live in userdata/server-browser/profiles/Default and have none of the user's cookies.
• Agent-opened tabs also disappeared between turns twice. PreviewManager.close shows up in the trace without the agent or the user closing them, and the next preview_status returns available: false. I didn't isolate a repro for this part.

Impact

Major degradation or frequent failure: the agent can't do any task on a page the user is signed in to, and it gives the user wrong instructions ("please log in") while their tab is visibly signed in.

Version or commit

T3 Code (Beta) desktop 0.1.0 (stable). Server serverVersion: "0.1.0", t3 v0.1.0.

Environment

Windows 10 Home 22H2 (build 19045), desktop app with its own local server (serverExposureMode: network-accessible; wslBackendEnabled: true but this thread runs on the native Windows server), Claude Code 2.1.305, Node 24.14.0.

Logs or stack traces

# userdata/logs/server.trace.ndjson
PreviewToolkit.invoke  Failure  PreviewAutomationTabNotFoundError: Preview tab tab_4 was not found for snapshot. Omit tabId to use the current tab, or call preview_open.
    at classifyResponseError (server.asar/apps/server/dist/binCli-CUds19Wg.mjs:299807:52)
    at Object.<anonymous> (server.asar/apps/server/dist/binCli-CUds19Wg.mjs:299963:57)
    at PreviewAutomationBroker.awaitResponse (…)
PreviewToolkit.invoke  Failure  PreviewAutomationTabNotFoundError: No active preview tab was found for snapshot. Call preview_open first.
PreviewManager.close   Success   # agent tab closed between turns; neither agent nor user closed it

# server process
"T3 Code (Beta).exe" --require …/app.asar/apps/desktop/dist-electron/compileCache.cjs …/server.asar/apps/server/dist/bin.mjs --bootstrap-fd 3
  parent: "T3 Code (Beta).exe"

# t3_preview_list() (private URL redacted)
{ tabId: "tab_4", navStatus: { _tag: "Success", url: "https://<private-helpdesk>/app/views/…" }, profileId: "default" }
{ tabId: "tab_7_0b68e34e-…", navStatus: { _tag: "Idle" }, profileId: "default", runtime: "server", automationOwner: "…" }

Screenshots

1. Tool outputs from the same moment. The user's tab is listed but can't be reached, and preview_open hands back a different tab. These are the real responses with the private URL redacted.

2. The agent's runtime: "server" tab on the same URL. It shows the site's login page, while the user's tab_4 in the same thread is signed in. That's why the agent kept asking the user to log in.

I didn't screenshot the user's own tab because it shows private customer data.

Workaround

None found inside T3. The agent had to fall back to a separate Chrome with remote debugging, or the user had to download the files by hand.

Filed by Claude Code (Opus 5.5) on behalf of @LeighAtkins, from the T3 Code thread where this happened.