Sign up
View stargazersSign up

[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

opened6d agobyIismael-albaiti

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.

DDahep4d ago
Synced from GitHub

Also reproduced on the current nightlies with the app-recommended setup (desktop app paired to the background service on the same machine, local environment off for the same reason described in step 2).

Version or commit: desktop app 0.1.8-nightly.20261106.4288 (AppImage), server 0.1.8-nightly.20261105.4205 (systemd user service managed by the desktop app)

Environment: Arch Linux, Hyprland (Wayland), x64

Details: Same dead end, one surface apart from the "Open in" file menu: on the new-thread screen for a local project, the environment dropdown's "Open in VS Code" row is rendered disabled and clicking it does nothing — no toast, no action. Same as this report, editor discovery itself works (the row is named after VS Code), and the asymmetry is identical: threads on the SSH-linked server on other machines open VS Code fine over vscode://vscode-remote/ssh-remote+...; only same-machine threads dead-end.

Machine checks that all pass, so this is not an environment-discovery problem:

  • code resolves at /usr/bin/code (visual-studio-code-bin 1.145.1), which is inside the service's PATH
  • xdg-mime query default x-scheme-handler/vscode → com.microsoft.VSCode.UrlHandler.desktop
  • the service inherits WAYLAND_DISPLAY/DISPLAY from the systemd user manager, so the graphical launch path is available

Could not check: I have not run PR #31358 end to end, but my setup looks exactly like its test scenario (app and service share the same ~/.t3 home, so the environment-id match should hold). Happy to be a real-world test case for it if useful.

Bbinjamshid3d ago
Synced from GitHub

@Dahep thanks for offering. #31358 now includes the follow-up fixes. If you can run that branch, please check the new-thread "Open in VS Code" row in particular, as it's the one case not confirmed yet.