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.
preview_open reports "timed out after 660000ms" when the real failure is a 15s page.goto navigation timeout#24278
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:
| 1 | 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
- On the server-browser host, the open request navigates with
waitUntil: "load"andtimeout = 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 fireloadon its first request. - The host replies with a
PreviewAutomationTimeoutError.classifyResponseError(apps/server/src/mcp/PreviewAutomationBroker.ts:210) builds a new error from the broker's request context, whosetimeoutMsis the 660_000 open budget (:556). Themessagegetter (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_openaccept atimeoutMs, or use a longer orcommit-level wait for the initial navigation.
Repro steps
- Run T3 Code as a server (background service) with the server browser.
- Start a Vite dev server whose first page load takes more than 15 seconds (cold dependency optimization or SSR compile).
- Right away, have an agent call
preview_openwith that URL. - Observe
Preview automation open timed out after 660000ms.returned in about 15–18 seconds.
Environment
- Server:
0.1.3-nightly.20261023.3592(also seen on0.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.