[Feature]: Add an authenticated browser preview gateway for served web

[tastelessjolt]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

The Browser surface is unavailable when T3 Code is used through the served web app. The current preview runtime depends on the desktop Electron webview, while the server owns preview discovery and state but does not expose project-local web servers to a remote web client.

This is especially limiting when the T3 server is on another machine: a preview target such as localhost:3000 refers to the environment machine, not the user's browser machine, and may be unreachable from app.t3.codes or a remotely served client.

Proposed solution

Add an authenticated, environment-scoped preview gateway to the T3 server. The web client could load a selected discovered preview target through a same-origin server route inside the existing Browser panel.

The gateway should proxy only an explicitly selected target belonging to the current environment and should reuse the existing preview target discovery and authorization model. This proposal is for displaying environment-hosted web apps; it does not require launching Chromium on the server or adding browser automation.

Why this matters

Remote-ready workflows are a core part of T3 Code. Users connected through served web currently lose a major feedback loop: they can run a development server through an agent but cannot view it in T3 unless they separately expose that port or switch to the desktop client.

Smallest useful scope

A first version only needs:

• One explicitly selected loopback HTTP target from the active environment
• An authenticated same-origin proxy route
• Normal document and subresource requests
• WebSocket forwarding so common development servers and HMR work
• Display in an iframe within the existing Browser panel
• No server-side Chromium, CDP automation, annotations, or multi-user preview ownership

Alternatives considered

• Continue requiring the desktop app. This does not address users who intentionally connect through served web.
• Ask users to expose every development port separately with Tailscale or another tunnel. This adds setup and bypasses T3's environment and authentication boundaries.
• Run a full headless browser on the server and stream it. That could support richer automation and otherwise unreachable sites, but adds much more resource, lifecycle, and security complexity than a preview gateway.
• Use a client iframe pointed directly at localhost. That resolves localhost on the wrong machine for remote users and fails for targets the client cannot route to.

Risks or tradeoffs

A proxy can become an SSRF or credential-exposure boundary if targets are not tightly constrained. The design needs explicit rules for allowed hosts and ports, authentication, authorization per environment, redirects, cookies, origin and host rewriting, CSP and frame headers, WebSocket upgrades, response size limits, and cleanup when a target disappears.

Some applications assume a particular origin or use absolute URLs, so compatibility will not be universal without additional rewriting.

Examples or references

• [codex] Add integrated browser preview, annotations, and agent automation #3053 introduced the integrated browser architecture and explicitly kept the actual browser in Electron rather than launching a server-side headless browser.
• [Feature]: Add Browser view of specific Git Worktree #1342 tracked the worktree-scoped integrated browser that is now available on desktop.
• Add browser panel with right panel tabs #1516 was an earlier, closed iframe-based browser panel attempt.
• feat(dev): Make t3 code dev instances shareable over Tailscale #4556 made T3 development instances shareable over Tailscale, but does not expose environment preview ports through the T3 origin.

Contribution

• I would be open to helping implement this.

[wojciechsacewicz]

this would be lovely

[RobbieFrancis]

I need this for my fleet.... How does everyone else maange previewing and testing changes on remote machines? Bored of remote'ing into the dev box to test.... very 80's.

[zucram]

Would love this! Would solve a lot of my problems!

[TunaCuma]

Would be awesome, I would love to see my localhost deploys.

[tpkowastaken]

This would be absolutely awesome. Would love to see this in T3 code

[illumin3dpb-ship-it]

+1, and one extra use case worth covering.

I run T3 Desktop on my home machine and often work from a laptop through the served web client. Chat works well remotely, but the Browser panel is empty because it depends on the desktop's Electron webview.

What I'd most like is to see the same Browser tab that's already open beside the chat on the desktop, with its logins, scroll position and unsaved form input, plus the page the agent is driving with the preview tools. Opening the same URL in a separate browser doesn't give me that: it's a different session.

Things I tried without changing T3:

• Proxying the dev server into a separate remote browser works, but it isn't the agent's tab, and logins are separate.
• Capturing the desktop's picture-in-picture window with OS window capture does show the exact tab. However, PiP frames are low resolution, so text is unreadable even when maximized. Resizing the window also ends the capture, and opening PiP needs the desktop window switched to that chat.

Two things would solve it, in order of preference:

1. Render the desktop's existing tab inside the web client's Browser panel. For example, stream the existing guest at its real size over the authenticated connection, view-only at first, with the agent's session unaffected.
2. The gateway proposed here, as long as an agent's preview tools can drive that same remote-visible page, so the human and the agent share it.

Happy to test a nightly build.