Treat same-machine saved environments as local for Open in and Reveal in file manager

[grahamfarrar]

Follow-up to #18473, as suggested there. Related bug: #7530.

Setup

The T3 server runs as the background service on a Mac (127.0.0.1:3773). The desktop app on that same Mac has Local environment turned off and connects to the service as a saved environment, so one server owns one database. Turning Local environment back on would start a second backend on the same T3 home (#14115, #17003). A second server with its own --base-dir (here, one per Claude account) is also saved as an environment at 127.0.0.1.

Problem

The app treats only its own Local backend as local. Every saved environment, including one at 127.0.0.1 on the same machine, goes through the remote path:

• Open in offers only "VS Code: Opens over SSH", with no Finder or other installed editors;
• file and folder chips have no "Reveal in file manager", only "Copy relative path" and "Copy full path";
• with no VS Code installed, there is no way to open a folder from T3.

Proposal

Treat a saved environment as local for Open in and Reveal when it is on the same machine. Either:

1. the server reports a machine identifier (the platform/hardware UUID, or the environment descriptor's machine info) and the desktop app compares it with its own; or
2. as a simpler heuristic, a loopback origin (127.0.0.1, ::1, localhost) counts as local when the desktop app is running on the same host.

Option 1 also covers #7530 (a same-machine browser reaching the server by LAN IP) and multi-server setups on one Mac.

[praveenperera]

Still happens on 0.1.0 (macOS). Same setup: the background service runs under launchd, the desktop app has Local environment turned off, and the service is added as a saved environment.

Two additions:

• It affects Zed too, not just VS Code. Open in Zed or VS Code builds an SSH deep link, so the folder opens as a remote SSH project on the same Mac. This needs Remote Login turned on.
• Since fix(server): enforce one database owner and guard update rollback #16102, this setup is the only supported way to run the desktop app and the background service together. The single-owner lock means the desktop's Local environment can't share ~/.t3 with the service, and Desktop quits on home-ownership refusal instead of offering to connect to the running background service #20250 was closed with this setup as the answer. So every user who keeps the service running for mobile or relay access gets the SSH round trip.

resolveRemoteOpenState in apps/web/src/remoteOpen.ts only returns local-exec for the desktop's own primary target or a local: connection id. A loopback check for bearer targets in the desktop renderer (option 2 above) would cover this case. The machine-identifier approach would also cover relay connections.

[fu5ha]

Yes, this is extremely annoying in particular since the latest version as praveen said above!

[i3130002]

I have never came across such a complex setup for a background service. Theo always focuses on the great UI/UX and to have my laptop as a T3 service and able to to use it with the GUI APP, I have to go through an impossible mission.

Not sure why the GUI App doesn't just use the service to connect and doesn't have a service option in the settings to run and maintain it's service so we don't have to juggle the service commands and GUI.

Used to work before this recent update but now we do need help for this issue.

[KinanLak]

@juliusmarminge asking for direction approval before opening a PR.

On #20250 you described this as the supported way to run the desktop next to the always-on background service: turn off Local environment, then add the service as a saved environment. In that setup, Open in, Reveal in file manager and the file preview's editor picker all treat the service as remote. They need SSH deep links, Remote Login, and a route back to the same machine (#18473).

#18473 noted the missing piece: "the server reports no machine ID that would let the app tell it's the same Mac". The desktop already has one. The service owns the same T3 home, and <stateDir>/environment-id is that server's own identity file.

Proposed scope:

• Desktop exposes one sync IPC that reads the environment ID stored in its T3 home.
• The web client treats the environment with that ID as this machine for resolveRemoteOpenState, the Open in picker and its editor list.

What it leaves alone:

• No server, contract-wire or settings change.
• With Local on, the ID equals the primary's, so nothing changes.
• Browsers and mobile have no desktop bridge, so nothing changes there.
• WSL backends keep their current behavior.
• [Bug]: Open in editor dead-ends at "No SSH route" for a same-machine browser reaching the server by LAN IP #7530 (a browser over a LAN IP) stays out of scope.

Open in still runs through that environment's own RPC, so a wrong ID gives the renderer no extra privilege.

The change is ready and tested: 16 files, about +150/−26, mostly tests and a param rename.

[BlackLight54]

I’m affected by this on Linux using the supported background-service setup described in #20250 : Local environment is disabled in the desktop app, and the app connects to a T3 Code service running on the same machine.

“Open in VS Code” generates an SSH Remote URI for this machine’s Tailscale hostname instead of opening the local path. Opening the same path with local VS Code works, and connecting through http://localhost:3773 classifies it correctly.

I would be happy to test the fix on Linux.

[grahamfarrar]

Another place the same gap shows up: browser profile cookie import. In Settings → Browser, "Import from" Chrome / Microsoft Edge / Safari is disabled with "Connect to an environment to import cookies", although the window is connected to the same-Mac saved environment over 127.0.0.1. The menu only enables for the desktop's own Local environment (the primary connection target), so a saved environment on the same Mac never qualifies. Treating same-machine saved environments as local would cover this too.

Desktop 0.1.0, server 0.1.2.