[Bug]: Open in editor dead-ends at "No SSH route" when the desktop app is paired to the background service on the same machine #30992

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Install the background service with t3 service install (Linux, systemd user service) and turn on LAN access in ~/.t3/service.env.
2. In the desktop app, Settings > Connections, turn off Local environment. With it on, the app refuses to start while the service runs: "This T3 home is unavailable ... You can also set a separate T3CODE_HOME and pair with the running server."
3. Pair the desktop app with the service using its pairing link.
4. Open a thread and open the "Open in" menu.

Expected behavior

The editors installed on this machine are listed and open locally, as they do with the desktop app's own local environment. The app and the server are on the same computer.

Actual behavior

The menu shows only "No SSH route to laptopIs" (disabled), and the "Open in VSCodium" button does nothing. Editor discovery itself works: the button names VSCodium.

Why I run it this way

• The service starts at boot, before I log in, so it is up whether or not the desktop app is open.
• It is reachable over my LAN and my NetBird tunnel behind a pairing code, so I use the same threads from my phone.
• Threads keep running when I close or update the desktop app.
• The server is independent of the client, so I can move it later (for example to my homelab) and only re-pair the desktop app.
• The desktop app's own error (step 2) points to pairing as the way to use a running service.

Diagnosis

resolveRemoteOpenState (apps/web/src/remoteOpen.ts, the function from #7530) keeps local-exec only for a PrimaryConnectionTarget in the desktop renderer or on a loopback host, or for a BearerConnectionTarget whose connectionId starts with local:, which only the desktop backend pool's own instances get. A paired service is a plain bearer target, so it is classified as remote. With no SSH profile and no remoteOpenTargets (no Tailscale, no mDNS), the state is remote-unavailable.

#7530 was the same dead end for a browser on the same machine reaching the server by LAN IP. This is the desktop app paired to a service, which 0.1.7 still classifies as remote.

Suggested fix

The desktop app already recognises a server running from its own T3 home (that is how it refuses to start a second one). It could give that paired connection a local target so Open in uses local-exec, or attach to the service as its local environment instead of refusing.

Impact

Minor bug or occasional failure (it fails every time, but the file manager is a workaround)

Version or commit

Desktop 0.1.7 (deb), server 0.1.7 (background service)

Environment

Linux Mint 22.3 Cinnamon, x64, X11

Workaround

Open files from the file manager or a terminal.