Repository navigation
[Bug]: Server-side browser makes previews blurry, with no way to opt out #16578
Description
Activity
Note
Grok responding on behalf of Julius.
Confirmed on current
main. After #15328, environments advertiseserverBrowser: true(ServerEnvironmentcapabilities), and the web client always picksruntime: "server"when that flag is set (previewRuntimeFor/readEnvironmentSupportsServerBrowser). There is no client or environment setting that opts preview tabs back to a local or desktop runtime.Streamed viewers hit
/api/preview-stream/wsas JPEG screencast frames. The server defaultsqualityto70(DEFAULT_QUALITYinServerBrowserStream.ts). The client never sendsquality— onlymaxWidth/maxHeight(packages/client-runtime/src/preview/serverBrowserStream.ts) — so every Connect / non-native viewer stays on that default. Recordings already use quality90(RECORDING_SCREENCASTinServerBrowser.ts).While scrolling, motion mode kicks in after 4 frames within 300 ms of a scroll (
SCREENCAST_MOTION_FRAMES/SCREENCAST_MOTION_WINDOW_MS): scale drops to0.5and quality is capped atSCREENCAST_MOTION_QUALITY(50). That matches the half-resolution + soft scroll artifacts in the report.Nuance for desktop: the primary desktop environment can still draw server tabs in a native
<webview>(rendersServerTabNatively), which is not the JPEG path. The Connect-relay / remote-viewer path (this report) always streams. Discussion #15339 is about which browser serves an agent when several desktops share an environment — related product choice, not a duplicate. #9872 is about screenshot quality in narrow previews, a different surface.Next steps (either or both):
- Add a setting (per environment or per client) to prefer desktop/local preview when available, instead of forcing
serverwheneverserverBrowseris advertised. - Raise the default stream quality (or pass
qualityfrom the client), and reconsider motion scale/quality for text-heavy pages. Recordings at 90 are a useful reference.
Pinning to
0.0.46-nightly.20261005.2689remains the workaround until then.- Add a setting (per environment or per client) to prefer desktop/local preview when available, instead of forcing
While I think it is super duper cool that T3 code now can access locally running dev servers, wouldn't it be better to just tunnel those through somehow and "access" the dev environments over the wire? Local browser rendering will always be faster than streaming something over the wire 🤔 On the other hand this could be nice for when I am on the phone and there is no preview browser, so making it somehow controllable would be super nice. In older versions this was easily solvable by just creating a skill which tells the agent how to give you a linkt that you can open via tailscale or some VPN over the integrated browser - enabling fast iterations with the agent. Now it's just impossible to use the integrated browser anymore in tandem with the agent haha.
Also minor nit: the new browser doesn't let you re-size the borders anymore, which is also a very big downgrade when you are on a small laptop screen, having to change the numbers in the top screen and not being able to just resize the window anymore.
Thanks for your efforts on this awesome software!
This is one of my many frustrations with this change. Additionally the latency and the lack of decent motion rendering you get with a stream. (even on the same local network). The lack of annotations (my favorite tool) and not being able to do a right click also feel like major degradation. I was unsure if it would be proper to create issues about all of these things so for the time being I'm just expanding on here.
I understand that this is a nightly and you have to start somewhere. I was hoping this would have been the resolution to work arounds I've been doing to painlessly access the remote machines dev services without tons of environment changes, but this streaming browser solution doesn't seem like a solution to my frustrations (hopefully it is for someone else's). I guess I was hoping for some solution like each remote T3 Code machine runs a SOCKS proxy and the machine you are working from uses that in its browser with the localhost proxy bypass disabled. (This would require the different remote environments to have each their own profile on your machine but you should be able to access localhost resources on the remote machine and not have to worry about port collisions between machines like you would if using SSH port forwarding)
Anyways, just trying to boost importance of this issue. Thanks for all the hard work from the contributors!
Reacted by Maximilian Zauner, Xanacas and Noah JadallahNow that Theo even showed off how to develop UIs fast with astra on ultafast, it's not even feasible anymore because the remote streaming is so laggy and sluggish lol 🫣
Add a setting (per environment or per client) to prefer desktop/local preview when available, instead of forcing server whenever serverBrowser is advertised.
I already had my Tailscale set up that my remote computer could tunnel my dev environment preview over to my phone & laptop. This has to be brought back as an option otherwise I will just have to revert the version I use.
I do want to add that there are definitely some difficulties with getting the exact link sometimes from the agent, that could definitely be handled better, but the streaming version is essentially useless.
+1 for a setting to opt out of the server browser. I run T3 on a headless Mac and use it from a MacBook and a phone over Tailscale. Every dev server is already reachable from my devices, so I want preview and agent tabs to open in the browser on the device I'm using, not in a headless Chromium on the server. A per-client or per-environment toggle to use the local or desktop browser runtime would cover it.
+1. Same setup here: T3 desktop on a Linux (Ubuntu) machine, used locally and from other devices over Tailscale. Our dev servers are already reachable from every device, so a local/desktop
<webview>render would be sharper and lower-latency than the headless Chromium stream. A per-client setting "Prefer desktop preview when available" would fully solve it for us.I see the benefit and the intent, but please let us have both options.
let the agent use the server side preview for the stuff that he is doing by default but, let me open my dev server as embedded browser tab clientside, while still having the annotation tools and the ability to let the agent control that tab.Let me set a default in the settings, and let me and the agent pick where to open a new tab.
Note
Grok responding on behalf of Julius.
Closing as fixed by merged #17316 — on desktop, user-opened tabs for remote environments now render locally instead of the blurry server stream, which is the opt-out this asked for. Agent tabs and web/mobile still stream.
Reacted by Maximilian Zauner
Before submitting
Area
apps/server
Steps to reproduce
0.0.46-nightly.20261006.2735and restart the server.preview_open.Expected behavior
Previews look as sharp as they did on
0.0.46-nightly.20261005.2689. If the streamed server browser is now the default, there is a setting to keep previews in the local or desktop browser, or at least to raise the stream quality.Actual behavior
Every preview is now a server-side Chromium screencast, sent to the client as JPEG frames. Text looks soft and edges show compression artifacts. While scrolling, the stream drops to half resolution and quality 50.
There is no setting to opt out:
serverBrowser: truein the environment capabilities.capabilities.serverBrowser === true ? "server" : undefined, with no user setting involved. The desktop app is also routed toserver, even thoughwindow.desktopBridge.previewis available./api/preview-stream/wsaccepts aqualityparameter (defaultDEFAULT_QUALITY = 70), but the client never sends one. The client does sendmaxWidthandmaxHeightin device pixels, so resolution isn't the cause.SCREENCAST_MOTION_QUALITY = 50, scale 0.5) starts after 4 frames within 300 ms of a scroll.Request: add a setting to turn off the server browser for preview tabs and use the desktop or local runtime, either per environment or per client. Separately, raise the default JPEG quality, or expose it as a setting. Recordings already use 90.
Impact
Major degradation or frequent failure
Version or commit
0.0.46-nightly.20261006.2735 (regression from 0.0.46-nightly.20261005.2689)
Environment
Linux x64 server running as a systemd user service; viewed through the T3 Connect relay.
Workaround
Pin the server to
0.0.46-nightly.20261005.2689, which has no server browser.