Which Browser should serve an agent session when several desktops share an environment?

[PixPMusic]

When more than one T3 Code Desktop is connected to an environment, the Browser tools can serve an agent's session from a desktop on a different machine. That desktop usually can't reach the dev server the agent is testing. I'd like maintainer direction before proposing a change, because the current routing was chosen deliberately in #13064.

What happens today

The server keeps one browser per agent session and treats every connected desktop for the environment as an equal candidate. For a new session, or after the assigned browser disconnects, it ranks desktops in this order:

1. shows a visible tab for the thread;
2. holds any tab for the thread;
3. reports focus;
4. focused most recently.

Nothing considers which machine the environment runs on.

"Focused" is per machine. A desktop sitting idle on another Mac with T3 Code in front reports focus indefinitely. In my case the agent's tab on the environment's own machine was hidden, so an idle laptop on the same network got the session. localhost URLs and environment-port targets then fail there. A url navigate fails because localhost is that laptop. An environment-port navigate fails because a T3 Connect client resolves it to the relay hostname, which is rejected. Assignments are never re-ranked, so opening the Browser panel on the right machine afterwards doesn't bring the session back.

The bug that made the session move mid-flow, eviction on wait_for timeouts, is fixed separately in #15335 / #15338. This discussion is about which browser should serve a session in the first place.

Possible direction

• Keep tab ownership first. If you have the thread's Browser tab open, including on a remote machine, that browser serves the session. "Look at what I'm looking at" keeps working when you drive a thread remotely.
• Then prefer the desktop that runs the environment's server. The server can verify this without new client claims: the desktop that launched it authenticates with a desktop-bootstrap session. npx t3 servers have no such desktop and would keep today's ranking.
• Then fall back to focus, as today.
• Make it visible. preview_status could report which desktop is serving the session, and an unreachable localhost/environment-port target could fail with an error the agent can act on (open the Browser on the environment's machine, or expose the dev server on a reachable address), instead of a generic "failed on client".

What I'd avoid: requiring the environment's own machine. That breaks remote use, for example driving a desktop at home from a laptop with nothing open at home.

Open questions

1. Should a pinned session ever move automatically to a browser on another machine, or should losing its browser surface an explicit error or handoff instead?
2. Should a user be able to hand a running session to the browser they're looking at ("use this browser")? Ranking alone can't do that, because pinned sessions are never re-ranked.
3. Is desktop-bootstrap provenance the right "same machine as the environment" signal, given that WSL also uses it?

[PixPMusic]

Update after finding related work: #13540 is the bug report for the failover itself, and #13772 is an open fix following its triage direction. Sessions keep the tab's desktop through a disconnect instead of failing over to any client.

#13772 deliberately leaves one case unchanged: when a session opens its first tab, any connected desktop is eligible and the focused one wins (#13064). That's the remaining question here. I hit it on two Macs: a brand-new session went to an idle second Mac, whose window was frontmost on its own machine, because the Mac running the environment wasn't focused at that moment. Every localhost page then failed there.

So I'm narrowing this to: for a session's first tab, should a desktop on the environment's own machine (desktop-bootstrap provenance) rank above focus on another machine? Should the agent see which desktop is serving it, for example in preview_status?

[TheLoroXD]

I have a working fork, commit b4c0be990, that lets users choose between the native client browser and a browser running on the owning environment.

My use case is to start an agent's browser task on a Linux host, disconnect my Mac, and reconnect to the same tab later.

With #15328 implementing the server browser and #14955 addressing session reconciliation, I'd like to build on that work with explicit browser selection:

• When opening Browser, choose the native client or the thread's environment.
• Remember the choice per environment and keep it stable for the agent session.
• If the selected browser becomes unavailable, return an actionable error instead of silently switching machines.

In my fork, a real Codex browser task completed on Linux 25 seconds after the client disconnected. Codex stored its final response while disconnected, and both web and a restarted Mac client recovered the same live tab. This verifies my fork; I have not run #15328. The test used a fictional loopback page and did not test physical laptop suspension or a host reboot.

Would maintainers support this selection model? If so, I can prepare a focused PR on top of the accepted server-browser work, with selection and reconnect tests. The contribution would be limited to browser selection, without the fork's custom app identity or packaging.

Prepared with GPT-6.1-Sol through the Codex harness in T3 Code.

[ImHangLi]

I have the same problem with a different setup, and I want to add the use case.

Setup

• Machine A (host) runs the environment server, the agents, and its own T3 Code desktop app.
• Machine B (client) runs the T3 Code desktop app and connects to the environment on machine A.

I work from machine B. When an agent calls a preview_* tool, the browser opens on machine B, because that window has focus. I want the browser on machine A for two reasons:

• My signed-in sessions and cookies are in the desktop app on machine A. The cookie import in docs/user/browser-import.md is a one-time copy into one desktop app, so it does not keep machine B signed in.
• The dev servers run on machine A, so localhost URLs only load there.

What I ask for

1. An explicit setting that selects the browser host for an environment: Automatic (same as today), This environment's machine, or The client I use. The setting pins the host. If the selected host is not available, the tool returns an error that names the host. This agrees with the selection model in the comment above.
2. A stream of the host browser to the other desktop clients. When the browser runs on machine A, the Browser panel on machine B shows it and sends mouse and keyboard input. The Device panel already does this for simulators through the environment server.

Why a better ranking is not sufficient for this case

In my case, I look at the thread on machine B, so "keep tab ownership first" and focus both select machine B. Only an explicit choice moves the browser to machine A.

Relation to #15328

#15328 says that the desktop app's own environment keeps Electron previews. That is machine A in my setup. I also want the host's Electron browser, because it has my signed-in sessions. A separate Chromium with isolated storage does not have them. A stream of the host's Electron browser to a second desktop client is the part that I did not find in the current work.

[PixPMusic]

I think #15328 might have solved most of this