[Bug]: Remote PDF previews start a download instead of rendering after server-browser switch #16853

Before submitting

• I searched existing issues and did not find a duplicate of this PDF/server-browser regression.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (preview), apps/web, apps/desktop

Summary

PDF links from a remote environment no longer display in the integrated browser of the macOS desktop client after the environment-hosted browser change in #15328. The PDF is served successfully, but the server browser starts a download instead of rendering it. T3 preview automation reports page.goto: Download is starting.

The user reports that this workflow previously worked. The current failure was reproduced independently through the T3 preview tools; an old-release A/B test has not been performed.

Steps to reproduce

1. Run the current nightly T3 server on a separate Linux x64 host and connect to it using the macOS T3 desktop app.
2. Put a valid PDF in the remote project's workspace and have a thread link it, e.g. [Report](/absolute/workspace/docs/report.pdf).
3. Open that PDF in the integrated browser from the chat file link. The environment advertises server-browser support, so remote tabs use the server runtime.
4. For an independent reproduction, open a browser tab through preview_open, then call preview_navigate with the PDF's fresh signed /api/assets/<redacted>/report.pdf URL.
5. Repeat with the same asset path through a direct LAN HTTP origin and through the host's existing HTTPS reverse-proxy origin.

Expected behavior

The PDF renders inside T3 as it did before the change. If the selected browser cannot render PDFs, T3 should offer a working document viewer or an explicit external-open/download fallback instead of treating the document as a navigable page that fails to load.

Actual behavior

The macOS client does not show the linked PDF. In the server-browser reproduction, both HTTP LAN and HTTPS asset URLs fail navigation with:

Preview automation navigate failed: page.goto: Download is starting

Evaluating the active server browser returns:

{
  "pdfViewerEnabled": false,
  "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/154.0.8037.92 Safari/537.36"
}

Independent GET requests through LAN, loopback, and HTTPS all return 200, Content-Type: application/pdf, Content-Length: 1559562, and bytes starting with %PDF-1.4. The file exists and the signed URL was unexpired during reproduction. This is not specific to the LAN route.

Regression investigation

#15328 merged on 2026-10-06 at 15:04:28 UTC, as ac8e9453ca0948469ccf5651b765086d8d9ecd64.

• openFileInPreview.ts now passes the runtime selected by previewRuntimeFor when opening file/URL previews.
• previewRuntime.ts selects server for environments supporting the server browser. Native desktop rendering is restricted to the desktop's own primary environment; remote environments stream the server tab.
• PreviewBrowser.ts installs Chrome for Testing headless shell, shared by server-browser tabs and HTML rendering.
• ServerBrowserContexts.ts launches it with headless: true.

This strongly points to the browser-runtime switch exposing the shell's unavailable PDF viewer, rather than an intentional PDF-disable setting. Current main (611132c171, checked 2026-10-07) retains this path; no specific fix was found. The live failure was reproduced on the installed nightly, not by building main.

Impact

Major degradation or frequent failure: generated study/report PDFs cannot be viewed in the remote integrated browser.

Version or commit

Server/web deployment reports 0.0.46-nightly.20261007.2774. Source reviewed: main @ 611132c171f3a821bd2e32f22261135cef6330ac.

Environment

Client: macOS T3 desktop app connected to a separate environment (exact desktop version not collected).
Server: Linux x64, systemd user service, Chrome for Testing headless shell 154.0.8037.92.
Routes tested: direct trusted-LAN HTTP, loopback HTTP, and existing reverse-proxy HTTPS. No credentials or signed asset tokens included.

Related reports

• [Bug]: Server-side browser makes previews blurry, with no way to opt out #16578: blurry server-browser previews and missing local-render opt-out after the same change.
• [Bug]: Streamed server-browser previews are high-latency and CPU-heavy on remote GPU-less hosts, with no local-render path #16827: remote server-browser latency and host CPU usage after the same change.
• [Bug]: Web clients can't open chat HTML/PDF file links in a browser #15929: older web file-link/menu and Files-panel issue, preceding feat(preview): run the browser on the environment server #15328; a different failure path.
• fix(web): open document file links in the correct viewer #16071: open document-link fixes for filename parsing/render preferences; does not address headless PDF rendering.

Workaround / possible fix

The asset itself remains retrievable: open its fresh signed URL in an external PDF-capable browser, or download it and use a native PDF reader.

Possible fix directions: render PDFs through a dedicated viewer such as PDF.js, or keep a PDF-capable client rendering path for remote desktop tabs. At minimum, handle download-start navigation explicitly with a usable fallback. Merely switching LAN HTTP to HTTPS does not fix this reproduction.

Generated with GPT-6.1-Sol. Harness: Codex through T3 Code.