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

opened1d agobyIiagorockel

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:

1Preview 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.

Synced from GitHub

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.