Repository navigation
[Bug]: preview_open still returns visible: false after explicit open/show request #17015
Description
Related issue
Possible recurrence of #3718, which is closed. This report captures a new observation on 2026-10-08.
Area
Collaborative browser / preview MCP tools.
Steps to reproduce
In a T3 Code thread using the Codex provider, ask the agent to open T3's browser and go to Google. The following exact tool sequence was executed:
preview_status({})returnedavailable: false,visible: false, andtabId: null.preview_open({"url":"https://www.google.com"})returned the response below.preview_open({"tabId":"tab_1","open":true,"show":true})returned the same response, includingvisible: false.
Actual behavior
Both open calls succeeded and returned:
{
"available": true,
"visible": false,
"tabId": "tab_1",
"url": "https://www.google.com/",
"title": "Google",
"loading": false,
"viewportSetting": {"_tag":"freeform","width":1280,"height":800},
"viewport": {"width":1280,"height":800}
}The agent reported that the preview was not visible. The user then asked what visibility meant and to whom. The exposed tool descriptions describe visibility but do not specify its observer or whether it is an immediate/eventually updated panel state. Therefore the agent could not justify interpreting visible: false as proof that the user could not see the browser.
This report does not establish that the user-facing panel was actually hidden; the confirmed observation is the returned status after the explicit open/show request. A later read-only preview_status({"tabId":"tab_1"}) returned visible: true with a different page, so the initial false state was not permanent. No intervening user interactions were captured.
Expected behavior
After an explicit open: true / show: true request, return visibility matching the resulting user-facing preview state, or clearly distinguish a pending display request from confirmed visibility. Document exactly what visible measures and whose view it describes, so agents can report it accurately.
Impact
Confusing user-facing status: a successful request to open the browser leads the agent to report that it is not visible, without enough information to explain that claim.
Environment
Linux, T3 Code with Codex harness, GPT-6.1-Sol. T3 Code version/commit was not captured.
Activity
juliusmarminge commentedon Oct 8, 2026
Note
Grok responding on behalf of Julius.
Thanks for the precise call sequence. I checked this against current
main(d720210). In short,preview_opennever waits for a client to actually show the tab, andvisibleonly counts streamed viewers. Details below.What's confirmed on main
preview_openis served by the environment's own browser, which registers as the preferred automation host (ServerBrowser.ts L2150-L2158). Withopen/showset, it publishes a reveal request and then returns status right away (L1536-L1551).requestRevealonly 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).preview_openandpreview_status,visibleis justtab.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 sayfalse. A laterpreview_statussaystrueonce the panel has connected. That matches what you saw.<webview>and are not streamed (previewRuntime.ts L26-L42, PreviewView.tsx L167-L170). There, no viewer is ever added, sovisiblestaysfalseeven 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 reportsattached/detached/cdp, with no shown/hidden signal (desktopBrowser.ts L21-L28).preview_statuslists "visibility" without defining it (tools.ts L65-L67), and the schema field has no description (previewAutomation.ts L77). Also, theopenparameter 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 returnedfalsewithout 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,fileChooserortabsfields, which main's server status always includes (L1115-L1155). Itsfreeform 1280×800viewport 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)
preview_openwait a short, bounded time for the tab to actually be shown (as the old host did) before reporting status.visibleisn't tied to streaming.visible, and documentvisibleas "a T3 client is currently displaying this tab."Workaround
Don't treat
visible: falseright afterpreview_openas proof the user can't see the tab. Re-check withpreview_statusafter a moment. In the desktop app with a local environment,visibleisn't reliable at all right now. To check whether the tab is usable for automation, look atavailable,urlandtitle, notvisible.Related
viewers.size > 0meaning. Open PRs feat(server,desktop): browser tools report why a page failed to load #16835 and fix(server): environment-hosted browser tabs behave like a normal browser #16963 also modifyServerBrowser.ts. None of them changes howvisibleis computed.earandap commentedon Oct 21, 2026
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)
10.0.26300.9711, T3 Code (Nightly)0.1.1-nightly.20261019.3360, Linux x646.18.33.2-microsoft-standard-WSL2server/default, Chrome Headless Shell 154.0.8037.92Sequence (the user had this thread open in the desktop app the whole time)
preview_status({})→available: false, visible: false, tabId: null.preview_open({url, open: false})→available: true, visible: false, tabId: tab_1_…(expected, background only).preview_open({tabId: tab_1_…, url, open: true})→ same,visible: false. The user reported no panel appeared.preview_open({url, open: true, reuseExistingTab: false})→ newtab_2_…,visible: false. Still no panel for the user.preview_statusontab_2re-read three times over the next ~10 minutes, including after the user signed in to the site in their own browser:visible: falseevery time, andtabs[]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 setsforce: trueon 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).
matthias-scale commentedon Oct 23, 2026
Another data point on T3 Code
0.1.3-nightly.20261023.3566, with a Linux server host:preview_open({"open":true})with no URL returnsavailable:true,visible:false,control.owner:"agent", viewport1280x800, and modefill. This adds a newer version and a no-URL call. The returned status alone does not prove the panel was hidden.11ten commentedon Oct 27, 2026
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:
preview_status({})returnedavailable:false,visible:false,tabId:null.preview_open({url:"https://example.com", reuseExistingTab:false, show:true, profileId:"incognito"})returnedavailable:true,visible:false, titleExample Domain,loading:false, viewport1280x800.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.preview_open({tabId, open:true, show:true})and subsequent status calls continued to returnvisible:false. The preview list showedruntime:"server", successful navigation,reveal:true, andrevealRequest.force:true. Its thread ID matched the actual test thread.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.
ElliotDrel commentedon Nov 4, 2026
Note
?? gpt-6.1-sol responding on behalf of Elliot
Reproduced with a local development page on Windows:
preview_open({open:true})returnedavailable:true,loading:false, an agent-owned tab, andvisible:false. Laterpreview_statusstill reportedvisible:false.preview_evaluateandpreview_snapshotthen timed out after 15000 ms. This establishes the returned tool state and automation failures; I could not independently confirm the user-facing panel visibility. No screenshots or private page contents are included.samwang0041-star commentedon Nov 10, 2026
Confirmed on T3 Code (Beta) 0.1.8, macOS 27.2 arm64, using the desktop app with its local server and the Codex provider. Browser access and auto-show floating preview are enabled.
The native desktop preview is visibly displaying the page while both
preview_openand subsequentpreview_statuscalls reportvisible:false.Reproduction
preview_open({url:"https://example.com", open:true}). It succeeds withavailable:true,visible:false,loading:false, titleExample Domain.preview_snapshotsuccessfully returns the rendered page and an accessibility tree. Click theLearn morelink throughpreview_act; navigation tohttps://www.iana.org/help/example-domainssucceeds.preview_statusagain on the same tab. It still returnsavailable:true,visible:false, titleExample Domains, withtabs[].visible:false.preview_evaluateon that tab returns:{ "title": "Example Domains", "url": "https://www.iana.org/help/example-domains", "visibilityState": "visible", "hidden": false }The preview session also records
runtime:"server",reveal:true, andrevealRequest.force:true.Source and release status
In v0.1.8's ServerBrowser.ts,
statusWithTitlestill computes both the top-level visibility (line 1624) and per-tab visibility (line 1651) using onlyviewers.size > 0. The existingisVisiblehelper already includesdesktopChannel.isShown(tab).I see that #23589 merged today and switches these fields to that helper. Please include the fix in the next desktop release; the current 0.1.8 package still reproduces this case.
The practical impact is misleading visible-browser acceptance: agents can interpret the false visibility status as a reason to launch external Chrome windows, even though the built-in preview is working. That creates unwanted browser windows and defeats the shared preview workflow.