Linked environments selects a Tailscale IP that its security check rejects #26450

Activity

1. Gabriel200622 commented on Oct 29, 2026

   

   Gabriel200622

   on Oct 29, 2026

   More actions

   Still reproduces on 0.1.6-nightly.20261029.3892 (both ends: Linux desktop AppImage → macOS desktop app, same tailnet, direct connection), via Settings → Linked environments → + Link, picking the machine from the list.

   One more detail that makes this harder to diagnose: the peer's advertised URLs include its own http://127.0.0.1:3773/. From the linking machine that loopback address answers as the local environment, so answeringAs gets one success with a non-matching environmentId. Because not every address was refused, the refusals.length === checked.length branch is skipped and the user gets the generic message with no reasons:

   PeerLinkError: This environment could not reach <Mac> at http://192.168.x.x:3773/, http://100.x.x.x:3773/, http://127.0.0.1:3773/.
   

   The span PeerLinks.answeringAs failed in ~8 ms. Both non-loopback addresses answer /.well-known/t3/environment with the right environmentId via curl from the linking machine. The real reasons (plain-http LAN and numeric Tailscale IPv4 both refused by peerOrigin) are never shown.

   Suggestions: don't offer a peer's loopback address to another machine, report refusals even when some other address answered as the wrong environment, and offer the peer's MagicDNS *.ts.net name, which isTailnetHost accepts.

   Workaround that works: t3 environment link http://<machine>.<tailnet>.ts.net:3773 --pairing-code <code> --access full-access, where the code comes from t3 auth pairing create --scope orchestration:read --scope orchestration:operate --scope settings:write --scope source-control:write on the peer. Linked and reachable.

   Produced by Claude Code (Claude Opus 5.5) via t3 triage (triage CLI 0.1.5).
2. NathanGlasby commented on Oct 29, 2026

   

   NathanGlasby

   on Oct 29, 2026

   Contributor

   More actions

   Still reproducible on the macOS desktop app, version 0.1.6-nightly.20261029.3892 (arm64).

   Linking my Linux environment automatically selected its numeric Tailscale address (http://100.x.x.x:3773/), then rejected it as plain HTTP.

   Workaround confirmed: manually adding and linking through http://<machine>.<tailnet>.ts.net:3773/ succeeded. Both linked environments now show Reachable.

   The numeric address was reachable; the failure was T3’s address validation.

   Investigated with Codex, GPT-6.1-sol.
3. Bafff commented on Nov 3, 2026

   

   Bafff

   on Nov 3, 2026

   More actions

   Still reproduces on 0.1.7-nightly.20261102.4093, and t3 environment link http://100.x.x.x:3773 --pairing-code … from the CLI fails the same way as the UI.

   One extra detail: because the peer's 127.0.0.1 URL answers (as the caller itself), the error shown is the generic "could not reach at " instead of the actual cause (the plain-http refusal), so it looks like a network problem. Surfacing the refusal reasons in that message would have saved a lot of debugging.

   (Comment written with Claude Code on behalf of @Bafff.)
4. KyleCole90 commented on Nov 4, 2026

   

   KyleCole90

   on Nov 4, 2026

   More actions

   Also reproduces on stable v0.1.7 at both ends: two macOS desktop apps (darwin arm64, macOS 27.2) on the same tailnet, with a direct Tailscale connection between them. I picked the MacBook in Settings → Linked environments → + Link on the Mac mini, and it fails every time.

   The error shown:

   PeerLinkError: This environment could not reach <MacBook> at http://192.168.1.127:3773/, http://100.64.96.40:3773/, https://<macbook>.<tailnet>.ts.net/, http://127.0.0.1:3773/.
   

   What each URL did (from the Mac mini's server.trace.ndjson; PeerLinks.answeringAs gave up after about 83 ms, 2026-11-04 13:17:34 UTC):

   URL	Result
   http://192.168.1.127:3773	Refused by peerOrigin (plain http to a LAN address); no request sent
   http://100.64.96.40:3773	Refused by peerOrigin, because isTailnetHost doesn't accept 100.64/10 IPv4; no request sent
   https://<macbook>.<tailnet>.ts.net	HttpClientError: Transport error, because the linking machine has Tailscale DNS (--accept-dns) off, so MagicDNS names don't resolve
   http://127.0.0.1:3773	Answered 200, but from the linking machine's own server, so its environment ID didn't match

   Further detail for this thread:

   1. Only the .ts.net URL passes the security check, and Tailscale config can make it unreachable without T3 saying so. In this setup it also depends on the target allowing inbound tailnet connections. The target has ShieldsUp: true, so TCP from the peer to 100.64.96.40 times out on every port even though tailscale ping succeeds. T3's error says nothing about this. Users who keep Shields Up on, or MagicDNS off, have no working link path at all, even though both machines see each other on the tailnet.
   2. The 127.0.0.1 answer hides the real cause again here. Because one URL succeeded (as the wrong environment), refusals.length !== checked.length, so the message drops the "plain http" refusals and looks like a network outage. Reporting each URL's outcome, or not counting a mismatched environment ID as a success, would have made this a one-minute diagnosis.
   3. The advertised list includes the target's own http://127.0.0.1:3773/, which can never reach the target from another machine.

   Environment: both ends run T3 Code (Beta) desktop v0.1.7, stable channel, macOS 27.2 arm64, server databaseMigration 79. The target exposes T3 via tailscale serve (tailnet only) proxying to 127.0.0.1:3773.

   Workaround: none that keeps these Tailscale settings. #26475 (accept a Tailscale machine's 100.x address) would fix this case. Note it would still need Shields Up off on the target, since the link needs an inbound connection.

   ---

   Triaged with Claude Code (Opus 5.5, claude-opus-5-5) via t3 triage.