[Bug]: preview_open still returns visible: false after explicit open/show request#17015

Thanks for the precise call sequence. I checked this against current main (d720210). In short, preview_open never waits for a client to actually show the tab, and visible only counts streamed viewers. Details below.

What's confirmed on main

• Since #15328 (Oct 6), preview_open is served by the environment's own browser, which registers as the preferred automation host (ServerBrowser.ts L2150-L2158). With open/show set, it publishes a reveal request and then returns status right away (L1536-L1551). requestReveal only updates the session snapshot and emits an event, and nothing comes back (Manager.ts L468-L497). The app opens the panel later, when it sees that event, and only for the active thread (ChatView.tsx L5513-L5543).
• In both preview_open and preview_status, visible is just tab.viewers.size > 0 (L1117). It means "some client has a frame stream open for this tab." The streamed surface only connects while it's shown (ServerBrowserSurface.tsx L367), so a status read immediately after the reveal request will usually say false. A later preview_status says true once the panel has connected. That matches what you saw.
• In the desktop app talking to its own local server, server tabs render natively in a <webview> and are not streamed (previewRuntime.ts L26-L42, PreviewView.tsx L167-L170). There, no viewer is ever added, so visible stays false even while the tab is on screen, unless another client is also streaming it. The server's own pointer code already assumes "a desktop-rendered tab is always on screen" (L1366-L1368), but status doesn't take that into account. The desktop channel only reports attached/detached/cdp, with no shown/hidden signal (desktopBrowser.ts L21-L28).
• The docs gap is real. preview_status lists "visibility" without defining it (tools.ts L65-L67), and the schema field has no description (previewAutomation.ts L77). Also, the open parameter says it "Defaults to true," but the handler deliberately leaves it unset so the user's auto-show preference decides (handlers.ts L36-L53).

Relation to #3718

#3718 was closed after #9484 merged. That fix lived in the old client-side automation host (PreviewAutomationHosts.tsx). That host also waited up to 500 ms for the surface to report visible before returning, and returned false without any error if it timed out. #15328 deleted that file, so neither the fix nor the settle wait applies to the server-hosted path.

Which path you hit (unconfirmed)

The response you pasted has no control, dialog, fileChooser or tabs fields, which main's server status always includes (L1115-L1155). Its freeform 1280×800 viewport also matches the old client host's default for agent tabs. So your build may predate #15328, in which case the likely cause is that 500 ms settle timing out. Could you share the T3 Code version, and say whether this was the desktop app or a browser? Either way, current main still shows the mismatch for the reasons above.

Possible fixes (not yet tried)

• After a reveal request, have preview_open wait a short, bounded time for the tab to actually be shown (as the old host did) before reporting status.
• Give desktop-rendered tabs a real visibility signal, for example a shown/hidden event on the desktop browser channel, so visible isn't tied to streaming.
• Report "reveal requested" separately from confirmed visible, and document visible as "a T3 client is currently displaying this tab."

Workaround

Don't treat visible: false right after preview_open as proof the user can't see the tab. Re-check with preview_status after a moment. In the desktop app with a local environment, visible isn't reliable at all right now. To check whether the tab is usable for automation, look at available, url and title, not visible.

Related

• #15328: introduced the server-hosted path.
• #9484 / #3718: the earlier fix.
• Open PR #16956 touches this same code and keeps the viewers.size > 0 meaning. Open PRs #16835 and #16963 also modify ServerBrowser.ts. None of them changes how visible is computed.
• #6355, #7212 and #16901 are in the same area, with different symptoms.

Another data point, on a newer nightly and on the Windows desktop + WSL server-runtime path (streamed tabs, not the local <webview> case).

Environment (2026-10-21)

Sequence (the user had this thread open in the desktop app the whole time)

1. preview_status({}) → available: false, visible: false, tabId: null.
2. preview_open({url, open: false}) → available: true, visible: false, tabId: tab_1_… (expected, background only).
3. preview_open({tabId: tab_1_…, url, open: true}) → same, visible: false. The user reported no panel appeared.
4. preview_open({url, open: true, reuseExistingTab: false}) → new tab_2_…, visible: false. Still no panel for the user.
5. preview_status on tab_2 re-read three times over the next ~10 minutes, including after the user signed in to the site in their own browser: visible: false every time, and tabs[] lists only agent-owned tabs.

So this is not just the "status read before the panel connected" timing described above: with an explicit open: true (which sets force: true on the reveal request), the panel never appeared and no viewer ever attached, across two tabs and ten minutes. The tab itself was fine for automation (available: true, navigation and snapshots worked), so the break is between the reveal request and the client opening the surface.

Impact: any flow that needs the human to act in the agent's tab (here, logging in to a Cognito-protected app so the agent can run screen checks) is blocked, since the user cannot reach the tab at all. The agent also has no way to tell "reveal lost" apart from "panel not connected yet".

Happy to collect more if you tell me what to look at (desktop logs, a specific server log line, or a debug build).

Another data point on T3 Code 0.1.3-nightly.20261023.3566, with a Linux server host: preview_open({"open":true}) with no URL returns available:true, visible:false, control.owner:"agent", viewport 1280x800, and mode fill. This adds a newer version and a no-URL call. The returned status alone does not prove the panel was hidden.

Additional reproduction on T3 Code 0.1.2, Linux host (Linux 7.2.8-9-omarchy x86_64), Codex provider. Observed 2026-10-27.

The user confirmed that the browser panel appears but stays blank or connecting. This observation comes from the client UI, not an inference from visible:false. The affected client is the T3 desktop app, confirmed by the user. Its version and operating system have not been captured; 0.1.2 is the verified Linux server runtime version.

Minimal test in a separate thread, using a new incognito tab:

1. preview_status({}) returned available:false, visible:false, tabId:null.
2. preview_open({url:"https://example.com", reuseExistingTab:false, show:true, profileId:"incognito"}) returned available:true, visible:false, title Example Domain, loading:false, viewport 1280x800.
3. preview_snapshot({tabId}) returned the page DOM, HTTP 200 for the document, and no console errors. preview_snapshot({tabId, save:true}) produced a rendered 1280x800 PNG, inspected locally.
4. preview_open({tabId, open:true, show:true}) and subsequent status calls continued to return visible:false. The preview list showed runtime:"server", successful navigation, reveal:true, and revealRequest.force:true. Its thread ID matched the actual test thread.
5. The user reported: "Panel appears but stays blank or connecting".
6. After that report, another saved snapshot succeeded immediately while status remained available:true, loading:false, visible:false.

Expected: opening the panel displays the loaded page, or reports an actionable connection error.

Actual: the user sees a blank/connecting panel while agent DOM reads and screenshots continue to work. This blocks interactive use of the browser from that client. No root cause is established, and the agent did not capture the client's DOM or network trace.

The successful snapshots distinguish this observation from the blocked-capture reproduction in #24852. #19420 also describes a connecting panel, but on a different host/client combination. Adding this here rather than opening another overlapping report.

No MCP transport failure recurred during this test. A prior isolated transport error and a separately resolved malformed URL were excluded from the reproduction.

Verified partial workaround: saved agent screenshots can show read-only page content. No interactive workaround has been verified.