Skip to content

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

Open
Open
[Bug]: preview_open still returns visible: false after explicit open/show request#17015
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@nima20002000
nima20002000
opened on Oct 8, 2026

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:

  1. preview_status({}) returned available: false, visible: false, and tabId: null.
  2. preview_open({"url":"https://www.google.com"}) returned the response below.
  3. preview_open({"tabId":"tab_1","open":true,"show":true}) returned the same response, including visible: 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

  1. juliusmarminge commented on Oct 8, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 8, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    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 feat(preview): run the browser on the environment server #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

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions