Choose a system-installed browser for T3 previews and agent automation

[ChiragM999]

Please let users choose a system-installed browser for T3’s integrated browser and agent automation, on both local and remote environments.

I use T3 on my laptop connected through managed SSH to a NixOS homelab. I want to install Chromium declaratively and have T3 use it instead of downloading its own browser:

environment.systemPackages = [ pkgs.chromium ];

This would let Nix manage browser dependencies, updates and rollbacks. Users should also be able to select another compatible installed browser, such as Chrome, Brave or Edge.

Suggested behavior:

• Keep T3’s current browser as the default.
• Allow selecting an installed browser or specifying its executable path through a setting or environment variable.
• Use it for collaborative previews, agent automation and browser-backed HTML renders where supported.
• For remote environments, use the executable on the remote host.
• Clearly report unsupported browsers or incompatible versions.

Chromium-based browsers would be a useful starting point; Firefox support would also be welcome if feasible. This concerns T3’s internal browser, rather than opening external links.

Current installed versions:

• Laptop: 0.0.46-nightly.20261009.2861
• Homelab server: 0.0.46-nightly.20261007.2774
• Homelab OS: NixOS 26.05, x86_64

Related: #16871 covers NixOS library detection; discussion #13132 covers external browser selection. Neither covers this request.

[immakermatty]

A variant for machines where a browser is already running: let the server browser attach to it over CDP instead of launching one.

Our case is a hosted Linux machine shared by a few people and their agents. One headed Chromium already runs there. It holds the sign-ins, and it's the window people actually watch. Agents should work in that browser, not in a separate chrome-headless-shell.

Choosing an executable doesn't solve that. A freshly launched browser has none of those sign-ins and isn't the window people see. #15339 has a related data point: a sign-in that passes in a browser driven over CDP loops in Playwright-launched Chromium.

Most of the attach path is already there. Desktop-drawn tabs connect with chromium.connectOverCDP (connectDesktopPage) and are treated as pages Playwright doesn't emulate:

• no viewport, zoom or user-agent overrides;
• no idle close;
• a disconnect doesn't close the browser.

Today that endpoint can only come from the desktop app's relay. A configured endpoint, e.g. T3CODE_SERVER_BROWSER_CDP_URL=http://127.0.0.1:9222, could reuse the same path:

• attach with connectOverCDP(endpoint, { noDefaults: true }) and work in the browser's default context, so its sign-ins are available;
• no chrome-headless-shell download or launch;
• T3's own preview tools and viewer stream keep working, unlike driving the browser through a separate MCP server;
• snapshots sized the way fix(server): desktop-drawn preview snapshots match the page's scale and viewport #19913 does it for desktop tabs.

Constraints we'd expect:

• loopback endpoints only;
• off by default;
• documented as giving agents every sign-in in that browser.

We run this downstream on 0.1.0, with upstream's ServerBrowserPage driving the attached pages. Happy to share what we learned or test a candidate.

[dpearson2699]

Another use case for this, from a macOS environment reached through T3 Connect:

An agent workflow needs a signed-in ChatGPT web session in the environment's browser: the agent opens chatgpt.com, submits a prompt, and later reads the response, so it must be able to see and drive the tab. Signing in with "Continue with Google" in that tab fails the same way #20867 describes. Google redirects to /v3/signin/rejected ("This browser or app may not be secure").

The workaround from #20867, Open on this computer, doesn't help here. The tab then runs on the connected device, so the agent in the environment can't see it. The agent needs the signed-in tab on the environment's side, which is where a user-selected full browser, or the CDP-attach variant above, would fit.

Version: T3 Code Nightly 0.1.1-nightly.20261019.3360, macOS 27.0.1, environment accessed remotely through T3 Connect.

[OsirisMedici]

Note

🤖 GPT-6.1 Sol responding on behalf of OsirisMedici

I reproduced the Google/YouTube sign-in rejection from #20867 on 0.1.4-nightly.20261027.3770. Adding the newer-version reproduction here, following the maintainer's direction in that issue.

My setup is T3's macOS nightly desktop app connected to a Linux VPS. Both installed client and server are 0.1.4-nightly.20261027.3770. The affected tab is the VPS server browser, using the persistent default profile and bundled Chrome Headless Shell 156.0.8078.70. The running application is the installed nightly, not a build of my fork.

Reproduction:

1. Open a fresh T3 shared-browser tab explicitly in Default (profileId: "default", reuseExistingTab: false); verify runtime server.
2. Open https://www.youtube.com/ and click Sign in. Google's normal email/phone form appears.
3. Click T3's Take control and attempt the sign-in manually.
4. Google redirects to https://accounts.google.com/v3/signin/rejected and displays Couldn't sign you in / This browser or app may not be secure, with a Try again button.

My screenshot shows T3's You have control indicator during the rejection. The agent did not type credentials. Account identifiers and authentication URL query parameters are omitted from this report.

The VPS DNS problem encountered earlier is separately fixed: a private HTTPS project route now renders in this same T3 browser. GitHub sign-in also works in the same Default profile; the agent verified OsirisMedici, closed the tab, reopened a fresh explicit-Default tab and verified the same signed-in account without another login. The observed failure is Google's sign-in rejection, not a finding that all account access or profile persistence is broken.

The workflow I need is remote project testing and agency work in signed-in websites while the VPS takes the load off my MacBook. The remote agent must be able to see and interact with that authenticated browser. The Open on this computer workaround described in #20867 does not meet that need if the environment's agent cannot access the moved tab.

My Codex browser already has a usable YouTube session, but we have not tested a matched fresh Google login there, so that is not a controlled browser comparison. We have not established the technical cause of Google's rejection or tested an alternate browser executable/CDP workaround. No active T3/browser restart, cleared data, or credential-store copying was used.

The focused reproduction and investigation record is OsirisMedici#2. A supported persistent browser path that remains accessible to the remote agent would address this use case.

[BusuL]

+1, with a reproducible data point from a Linux server (t3 serve, nightly 0.1.4-nightly.20261027).

Same page, same machine and network, same launch flags as T3's server browser (--disable-blink-features=AutomationControlled, no --enable-automation), Cloudflare Turnstile on a site we own:

• bundled chrome-headless-shell 156.0.8078.70: UA HeadlessChrome/156…, no Turnstile token after 40 s, widget reports it could not load
• host-installed Google Chrome 156.0.8078.73, run headed on Xvfb: UA Chrome/156…, navigator.webdriver === false, Turnstile token issued in a few seconds

Our current workaround is a small shim in place of the bundled executable that execs system Chrome in --headless=new mode with a regular Chrome user agent (dropping --disable-gpu), re-applied by cron after T3 updates the bundled browser. With it, Turnstile passes inside the real T3 server-browser panel too. (Running headed on Xvfb also passed in a standalone test but failed T3's browserContext.newPage in the panel.) A supported setting such as the one in PR #26595 (T3CODE_SERVER_BROWSER_EXECUTABLE), ideally with a headed/Xvfb option for servers, would make this unnecessary.

[AzureDominus]

+1, with a side-by-side from a Linux server (t3 serve 0.1.6, Ubuntu 24.04 VP).

Use case: personal-assistant agents doing groceries and bookings on logged-in sites. That needs a regular browser with a persistent profile and an ad blocker, ideally the one already running for the assistant (the CDP-attach variant mentioned above).

Same host, same IP, same day, fresh profiles, one run each:

Browser	bot.sannysoft.com	BrowserScan bot test	Fingerprint Pro demo	Cloudflare challenge page
T3 server browser (chrome-headless-shell 156)	window.chrome missing, 0 plugins, SwiftShader WebGL, HEADCHR_IFRAME fail	not run	not run	not run
Chrome 156 stable, --headless=new	HEADCHR_UA, CHR_MEMORY, UA, WebGL flagged	Robot	"bad bot (headless_chrome)"	stuck
Chrome 156 stable, headed on Xvfb	only WebGL flagged (no GPU on the VPS)	Normal	bot not detected	cleared
Brave 156, headed on Xvfb	only WebGL flagged	Normal	bot not detected	cleared

So on the same machine the gap comes from the headless build/mode, not the host. Running a regular browser headed on Xvfb closes most of it.

Two notes for whoever picks this up:

• presentAsChrome rewrites the client-hint brands to "Google Chrome". With a user-supplied Brave, Edge or Helium that would contradict the browser's own brand (Brave also exposes navigator.brave), so it should probably only apply to the bundled headless shell.
• CDP signals are separate from the binary. A driver that sends Runtime.enable (the Playwright/Puppeteer default) gets flagged by deviceandbrowserinfo.com (isAutomatedWithCDP) and shows "Developer Tools: yes" in Fingerprint Pro. The same browser driven without Runtime.enable reads as human on both. I'm not asking T3 to solve that here, just setting expectations: a real browser fixes the headless signals, not the CDP ones.

(Measurements and write-up done with Claude Code.)

[TweakingGuy]

Note

🤖 Claude Opus 5.5 responding on behalf of TweakingGuy

A Discord/hCaptcha data point from a Linux VPS (t3 serve 0.1.8-nightly.20261105, datacenter host, macOS desktop client, bundled chrome-headless-shell 156.0.8078.80).

Real-account QR login in the server browser, through an ISP proxy: in one session, the hCaptcha challenge recurred and POST /api/v9/users/@me/remote-auth/login returned 400, then 404, and the QR code reset. The captcha was solved by the person logging in. The 400 response body was not captured, so the cause remains unknown. The 404 may just be an expired QR ticket.

hsw.js: in chrome-headless-shell 156, Chrome --headless=new and headed Chrome on Xvfb, all launched through Playwright with --disable-blink-features=AutomationControlled and run through an ISP proxy, hCaptcha's hsw.js logs the same EvalError on its demo page. I could only read the console over CDP, so I have no control from a browser that isn't automated, and I haven't established whether the error affects authentication. If the check looks at the debugging connection rather than the browser binary, swapping the executable alone may not help. That would fit the Chrome for Testing run in #24256, but it's a guess.

For one-off sign-ins, Open in system browser is the maintainer-recommended alternative (#24256). If the executable or CDP-attach direction here moves forward, I can rerun these checks on it.