[jakeleventhal]

Problem

Tailscale HTTP and HTTPS routes had equal priority, so discovering HTTP first left it ahead of HTTPS. Reported here.

Change

Prefer Tailscale HTTPS when inserting newly added or learned routes in the shared web, desktop, and mobile runtime. LAN stays first, HTTP remains a fallback, and existing saved order is preserved, including manual preferences.

Scope and approval

Focused correction to existing connection route ranking, with regression tests and matching user guidance. No new setting or workflow.

Verification

• Four assertions fail against current main's route logic, covering insertion, discovery, later HTTPS availability, and HTTPS-paired credential routing.
• vp test run packages/client-runtime/src/connection/routes.test.ts packages/client-runtime/src/connection/registry.test.ts packages/client-runtime/src/connection/supervisor.test.ts: 117 tests passed, covering both discovery orders, LAN priority, and saved ordering.
• vp run check:changed: format, lint, knip, affected typechecks, and adjacent tests passed.
• git diff --check passed. Chrome verified fixture-route insertion and persisted manual reordering. Live Tailscale connectivity and native client execution remain unverified.

Written with GPT-6.1 Sol through the Codex harness.

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — Newly added or learned routes now prefer Tailscale HTTPS over HTTP, changing automatic connection-route priority. This default preference requires human review, although users can still reorder routes manually.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: c6ef3b4
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 5ecd9240-42fd-44c5-82bc-03881b5b6be6

Commits

Reviewing files that changed from the base of the PR and between 077c125 and 545b4e8.

Files selected for processing: 2

• docs/user/remote-access.md
• packages/client-runtime/src/connection/routes.test.ts

Limit details: You’ve used all 10 included reviews currently available.

Walkthrough

Tailscale HTTPS routes now rank ahead of Tailscale HTTP routes during insertion. Tests cover insertion and learned-route ordering, including manual ordering and routes that share a credential. The remote-access documentation describes the HTTPS preference.

Changes: Tailscale route precedence

Layer / File(s)	Summary
HTTPS route ordering packages/client-runtime/src/connection/routes.ts, packages/client-runtime/src/connection/routes.test.ts, docs/user/remote-access.md	insertRoute applies an adjusted rank to Tailscale HTTPS routes. Tests cover insertion order, learned routes, shared credentials, and preserved manual ordering. The documentation states that HTTPS is preferred over HTTP.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#26757: Both changes affect how the client runtime handles direct tailnet routes and their relative ranking.
• pingdotgg/t3code#25852: Both changes affect learned-route handling and ordering for routes that share a credential.
• pingdotgg/t3code#25591: Both changes modify route insertion ordering.

Suggested reviewers: juliusmarminge, macroscopeapp

Merge Risk: Minimal · up to 545b4

The change is ready to merge after normal checks.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "fix(connections): prefer Tailscale HTTPS routes" is a conventional commit title that names the primary change. The changeset updates route ranking in routes.ts so Tailscale HTTPS routes are…
Description check		The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections. The Problem and Change sections state the issue and the fix clearly. The Scope s…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title "fix(connections): prefer Tailscale HTTPS routes" is a conventional commit title that names the primary change. The changeset updates route ranking in routes.ts so Tailscale HTTPS routes are inserted ahead of Tailscale HTTP routes. The tests and user documentation cover the same behavior.

Full details: Description check

Explanation

The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections. The Problem and Change sections state the issue and the fix clearly. The Scope section explains why the change is a focused correction to existing ranking and does not add a setting or workflow. The Verification section lists specific tests, results, and unverified areas. The template's approval requirement is addressed by a focused-fix justification rather than a linked issue. The description does not link a triaged issue or maintainer approval comment, so a reviewer may want to confirm that the focused-fix exemption applies. The description also omits the model and harness line in a form that matches the template, although it names GPT-6.1 Sol and the Codex harness.

Finishing Touches: 💡 1

🛠️ Fix failing CI checks: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 2
• Charged: $0.50
• View usage details

Note

This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

thanks @jakeleventhal. your insertion-only fix already keeps saved/manual order and http fallback intact, so i kept the implementation, tests, and guidance unchanged. i merged current main (6d12bb1e9fbd) into your branch without rebasing. head: 077c1250134c4860656310804c92946607359c09.

verification:

• four assertions fail with main's routes.ts; the fix passes all 117 focused route, registry, and supervisor tests.
• blacksmith vp run check:changed passes format, lint, knip, typechecks for seven affected packages, and adjacent tests. git diff --check passes.
• chrome exercised the real client catalog registration path with fixture routes added in matching order: lan, http, https, and t3 connect. https moves ahead of http while lan stays first. manually dragging http above https survives reload.
• live tailscale connectivity and native mobile/electron execution remain unverified. the ordering implementation is shared by all three clients. screenshots demonstrate fixture route ordering, not live tailnet connectivity.

before, main's insertion logic:

after, this branch with the same routes:

github confirms this head is mergeable: 21 checks passed, 10 skipped, none pending or failing. two independent gpt-6.1-sol reviewers approved this head without findings. the intentional default-priority change still needs maintainer review. cafe currently shows the previous head, so github was used to verify the current revision.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

checked unchanged head 077c1250134c4860656310804c92946607359c09 on a disposable linux boat vm. read the diff, description and discussion; the pr is open and its two commits are by jake and maria.

• started github/main (6575ce3250) in ../main after vp i, with fresh isolated state. stopped its captured process group before starting the exact pr head after its own vp i. only one dev server ran at a time.
• used repo playwright and /usr/bin/google-chrome. paired through the web ui and added the real /home/user/t3code git repository through the local-folder flow. used no mocks, fixture routes, demo data or database writes.
• on the pr, selected codex gpt-6.1-sol and submitted a real turn through the composer. the provider completed successfully and the client displayed route verification online.
• a fresh browser context restored the thread and completed another real codex turn, displaying reconnect verified. both responses survived reload. settings > environments and the add-environment dialog opened normally.
• inspected the screenshot and recording, then checked uploaded video playback and seeking in the t3 browser. these captures prove the local provider/client path, not tailscale route preference.
• github reports 20 successful checks, 10 skipped, none pending or failing. no source changes or pushes were made.

command and provider transcript

item/completed: "route verification online."
turn/completed: status=completed, error=null
item/completed: "reconnect verified."
turn/completed: status=completed, error=null
reload: both responses visible

Not verified

the changed tailscale behavior remains unverified. this vm has no tailscale executable, daemon or authenticated tailnet. main had no saved remote environments, so i could not reproduce the original http-before-https bug through real discovery. consequently i could not prove the pr prefers a newly discovered https route, keeps http fallback and lan priority, or preserves manual/saved ordering against live endpoints. the existing fixture screenshots and green ci do not establish that runtime result. no synthetic routes were substituted.

to finish this verification, use an authenticated tailnet with working http and tailscale serve https endpoints, reproduce http-first discovery on main, repeat on this head, then check manual reorder persistence and http fallback when https is unavailable.

the main provider log contained the requested response but its client did not display it during observation; this separate baseline issue was not changed. the pr displayed both responses. native electron, ios and android, remote relay/tunnel paths, and live tailscale connectivity were not exercised.

result: central feature unverifiable in this environment; local web/provider checks passed.