[Bug]: preview_open ignores an explicit desktop tabId and creates a new server tab #19718

Activity

1. juliusmarminge commented on Oct 15, 2026

   

   juliusmarminge

   on Oct 15, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   This is a bug in how preview_open handles an explicit tabId. It is not about WSL desktop control, which is out of scope on purpose.

   A WSL server can't drive a tab hosted on the Windows desktop, and that has been by design since #15328. What's wrong is the fallback. On main, findTab in apps/server/src/preview/ServerBrowser.ts only matches runtime === "server" sessions. The open handler turns ServerBrowserTabNotFoundError into undefined and then opens a new server tab, even when tabIdExplicit is set. The agent gets a success result for a tab it didn't ask for. That contradicts the tool description ("Pass tabId to reuse a specific existing tab"). It's also inconsistent with the other preview handlers, which return PreviewAutomationTabNotFoundError for an unknown tab.

   Expected fix: when tabId is explicit and can't be resolved, open should fail. If the tab exists but lives on the desktop runtime, the error should say that, and no new tab should be created. Implicit reuse can keep its current fallback.

   Related but separate: #17090 (Windows/WSL browser limitations) and discussion #15339.
2. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 15, 2026
3. seankoji commented on Oct 15, 2026

   

   seankoji

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on 15 October 2026 (AEDT), reported with the user's permission. Agent: Codex in T3 Code. The Linux server service is configured to run 0.0.46-nightly.20261009.2873; the connected desktop version was not independently checked.

   The same explicit-tab fallback blocked a Cloudflare workflow:

   1. The user had two existing Browser tabs open at https://dash.cloudflare.com/profile/api-tokens and reported that both worked and were signed in.

   2. t3_preview_list({limit:50}) listed tab_1 and tab_3, both with title Cloudflare Dashboard | Manage Your Account. Their session records had no explicit runtime field.

   3. preview_status({}) listed only the agent's separate server-runtime tab. It omitted those two user tabs.

   4. Targeting the listed user tab failed:

      {"tabId":"tab_3"}

      preview_snapshot returned:

      Preview snapshot failed: Preview tab tab_3 was not found for snapshot. Omit tabId to use the current tab, or call preview_open.
      

   5. Following that recovery advice with preview_open:

      {"tabId":"tab_3","reuseExistingTab":true,"open":true}

      returned success with a different, newly created blank tab:

      {
        "available": true,
        "visible": false,
        "tabId": "tab_5_<server-epoch>",
        "url": null,
        "title": null
      }

      The epoch suffix above is redacted; the different tab number and blank URL are from the actual response. No URL was requested in this call.

   Earlier agent-created tabs at the Cloudflare URL remained on Performing security verification, while the user reported their existing tabs worked. This illustrates the practical cost of switching browser sessions silently; it does not establish that the fallback causes Cloudflare's verification failure.

   The extra agent-created tabs were closed through t3_preview_close. A subsequent t3_preview_list still listed the two original user tabs. No token permissions or Cloudflare configuration were changed.

   Please preserve an explicit target: if the listed tab is hosted on an unsupported runtime, return that limitation without creating a replacement. The current snapshot recovery advice also sends the agent directly into the misleading successful fallback.

   No credentials, cookies, private transcript, or raw browser logs are included.
4. juliusmarminge

   closed this as completedin #19737on Oct 18, 2026