fix(settings): flag pairing links that only work on this network - #69
Merged
Conversation
enisze
force-pushed
the
fix/pairing-local-network-diagnostics
branch
from
August 28, 2026 18:24
1396f31 to
e907807
Compare
The pairing row hands over a LAN address without saying it is one, so the requirement to be on the same network is only discoverable by failing on the other device — where it arrives as a transport error. Name the host and the constraint next to the link, following the backend host inside hosted links rather than the hosted app's own domain. Tailnet addresses stay unflagged, since they route over the tailnet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
enisze
force-pushed
the
fix/pairing-local-network-hint
branch
from
August 28, 2026 18:24
f13502e to
046166a
Compare
enisze
changed the base branch from
fix/pairing-local-network-diagnostics
to
main
August 28, 2026 18:24
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #68 (which adds the
isPrivateNetworkHostnamepredicate this uses). Base is that branch, so review the top commit only; retarget tomainonce #68 lands.Problem
The desktop pairing row hands the other device a LAN address —
http://192.168.1.21:3773/pair#token=...— with nothing saying it is a LAN address. The requirement to be on the same network is only discoverable by failing on the other device, where it arrives as a transport error with no context.#68 makes that failure explain itself on the receiving device. This says it before you walk over to the phone.
Change
resolveLocalNetworkPairingHost(inpairingUrls.ts, alongside the existing helpers) returns the backend host when a pairing URL points somewhere local-network only, andnullotherwise. The pairing row renders it under the link:It follows the backend host inside a hosted link's
hostparameter rather than the hosted app's own domain, so a hosted link wrapping a LAN backend is flagged too. Tailnet addresses stay unflagged — they route over the tailnet, where the advice would be wrong.Tests
6 cases in
pairingUrls.test.ts: direct LAN URLs (IP and.local), the hosted-linkhostparameter, routable and tailnet hosts staying quiet, and non-URL input.src/components/settingssuite green (9 files, 55 tests); lint, format, and typecheck clean.🤖 Generated with Claude Code