Before submitting
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
Contribution
Before submitting
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:
Alternatives considered
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
Contribution