Repository navigation
[Bug]: Paired remote environment is never saved or shown in the macOS desktop app, though the server-side link and browser pairing work #33425
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
Setup: macOS desktop app (Mac) plus a Windows machine running t3 server 0.1.7 (PC), both on the same tailnet. The PC's server listens on 0.0.0.0:3773 and is also published through Tailscale Serve over HTTPS.
- From an agent thread on the Mac, link the PC with the environment link tool. The Mac server reports the PC as
reachable,full-access, and agents on the Mac can list its projects and launch threads on it. - Restart the Mac desktop app and look at the sidebar.
- Pair from the desktop app's link card with a code from
t3 pairon the PC. - Pair again through the PC's Tailscale Serve HTTPS URL (
https://<pc>.<tailnet>.ts.net:<port>) with a fresh code. - Open
https://<pc>.<tailnet>.ts.net:<port>/pair#token=<code>in a browser on the Mac.
Expected behavior
After pairing, the PC appears in the desktop app's sidebar with its projects and threads, and threads launched on it open in the app.
Actual behavior
- The PC never appears in the desktop app, not after a restart and not after any pairing attempt. Its 8 projects and the threads launched on it don't show either.
- Thread links that point at the PC (
t3-thread://v2/<pc-environment-id>/...) don't open in the app. - The browser pairing (step 5) works: the PC's T3 opens with all its projects and threads.
~/.t3/userdataand~/Library/Application Support/t3code-v2on the Mac contain noconnection-catalog.jsonand no reference to the PC's environment ID or address. The pairing is not persisted on the client at all. The logs show no "Could not load the local connection catalog" error, so this looks different from [Bug]: V2 desktop seeds t3code-v2 Local State from a stale "T3 Code (Alpha)" profile, making connection-catalog.json undecryptable #15001 and [Bug]: Orphaned safeStorage key makes connection-catalog.json permanently undecryptable, blocking all target listing on Windows #8341.t3 pairon the PC advertiseshttp://192.168.56.1:3773/pair#token=..., a Hyper-V or VirtualBox host-only adapter address that other machines can't reach. The first pairing attempt (step 3) failed with "That pairing code is unknown, expired, or already used."create_threadswithtarget.environmentIdset to the PC ignored that target and created the threads in the Mac's current project.t3_thread_launchwithenvironmentIdcorrectly created them on the PC.
Impact
Major degradation or frequent failure
Version or commit
0.1.7 (desktop and server on both machines)
Environment
Desktop app on macOS 27.0.1 (arm64); remote server on Windows x64; connected over Tailscale.
Logs or stack traces
t3 pair (on the Windows host):
Pairing with PC (http://127.0.0.1:3773).
Pairing URL: http://192.168.56.1:3773/pair#token=<redacted>
Note: This URL works only from this machine's local network. From elsewhere, re-run with --tailscale or use T3 Connect.
Activity
juliusmarminge commentedon Nov 9, 2026
Ran this on main (b8c2cfa) with the Linux desktop app as the Mac and a second
t3 serve --lanserver as the PC.t3 environment linkcreates an agent-to-agent link. It shows up only under Settings → Environments → Linked environments and lets agents on this machine work there. It doesn't add the machine to this app's sidebar or writeconnection-catalog.json. After the link, Environments listed the PC as "Full access · Reachable" under Linked environments, with "No saved remote environments" above it, which matches what you saw. To see the PC's projects and threads (and opent3-thread://links to it) in the desktop app, pair it as a client: Settings → Environments → Add environment, then paste a pairing URL from the PC, such as the Tailscale Serve HTTPS one. Done that way, it was saved, connected and written to the catalog.t3 pairadvertising192.168.56.1. Reproduced with a Windows host's adapters: the VirtualBox (and VMware) host-only adapters weren't filtered by their Windows names. Fixed in fix(server): t3 pair skips Windows VirtualBox and VMware host-only adapters #33441. Until that ships,t3 pair --tailscalegives a reachable URL.create_threadswithtarget.environmentId.create_threadsonly creates threads in the calling thread's checkout and has noenvironmentIdfield.t3_thread_launchwithenvironmentId, which worked for you, is the tool for another environment.norbert-pap commentedon Nov 9, 2026
Thanks, that clears it up. I'd assumed a linked environment would show up in the sidebar. Pairing as a client is what I needed, and I'm doing that now. Using
t3_thread_launchfor the remote work makes sense too.One more thing about
t3 pair --tailscaleon the PC: port 443 on that tailnet node was already taken by another service, so it failed withServePortOccupiedErroruntil I passed--tailscale-serve-port 8443. The error message said exactly what to do, so I'm only mentioning it in case it's worth a line in the pairing docs.I'll watch for #33441.