Skip to content

preview_open reports "timed out after 660000ms" when the real failure is a 15s page.goto navigation timeout #24278

Closed

Description

@iagorockel

What happened

An agent restarted a local Vite / TanStack Start dev server and called preview_open({url: "http://localhost:1337/", reuseExistingTab: false}) about 25 seconds later. The call failed after about 16 seconds with:

Preview automation open timed out after 660000ms.

The server trace shows the real cause: [cause]: Error: page.goto: Timeout 15000ms exceeded. This reproduced twice, on two nightlies. Once the dev server was warm, the same call succeeded.

Because the message claims an 11-minute timeout, the agent concluded that preview was "stuck for 11 minutes" in this environment and started installing its own Playwright Chromium as a workaround.

Diagnosis

  1. On the server-browser host, the open request navigates with waitUntil: "load" and timeout = Math.min(request.timeoutMs, NAVIGATION_TIMEOUT_MS), which is 15000 (apps/server/src/preview/ServerBrowser.ts:1780, :1429). A cold Vite dev server often needs more than 15 seconds to fire load on its first request.
  2. The host replies with a PreviewAutomationTimeoutError. classifyResponseError (apps/server/src/mcp/PreviewAutomationBroker.ts:210) builds a new error from the broker's request context, whose timeoutMs is the 660_000 open budget (:556). The message getter (packages/contracts/src/previewAutomation.ts:952) prints that context value, and the remote message ("page.goto: Timeout 15000ms exceeded") is lost from what the agent sees.

Suggested directions:

  • Report the host's actual timeout, or include its message.
  • Consider letting preview_open accept a timeoutMs, or use a longer or commit-level wait for the initial navigation.

Repro steps

  1. Run T3 Code as a server (background service) with the server browser.
  2. Start a Vite dev server whose first page load takes more than 15 seconds (cold dependency optimization or SSR compile).
  3. Right away, have an agent call preview_open with that URL.
  4. Observe Preview automation open timed out after 660000ms. returned in about 15–18 seconds.

Environment

  • Server: 0.1.3-nightly.20261023.3592 (also seen on 0.1.2-nightly.20261021.3473), Linux x64 VPS, background service.
  • Client: T3 Code Nightly desktop app on macOS, connected to the remote server over Tailscale.
  • Provider: Claude agent (claude-opus-5-5).
  • Triage CLI: 0.1.2.

Evidence

  • PreviewAutomationBroker.invoke: started 23:33:52.197Z, duration 17787ms, Failure. Started 23:36:37.157Z, duration 15545ms, Failure.
  • Both failures: PreviewAutomationTimeoutError: Preview automation open timed out after 660000ms. with [cause]: Error: page.goto: Timeout 15000ms exceeded.

Related issues

#22594 (same message, but there the call really did block for 11 minutes), #16921.


Triaged and drafted by Claude Opus 5.5 (claude-opus-5-5) via Claude Code, using t3 triage.

Activity

  1. Ethereal49 commented on Oct 24, 2026

    @Ethereal49
    Contributor

    I can take this. I will reproduce the 15-second navigation timeout through the preview automation path, preserve the existing navigation behavior, and fix only the surfaced timeout diagnostic so it no longer reports 660000ms. I will add focused tests around host-to-broker timeout propagation. I have not independently reproduced it yet.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions