[Bug]: After re-pairing, an environment's other routes keep the expired login, and removing a route deletes the new one#17014

Thanks for the detailed write-up. I checked it against main (14fe0158ed) by reading the code; I haven't run the repro on a device.

Confirmed in code

• Credentials are per route. A paired route's id is bearer:<envId>:<origin> (onboarding.ts#L94-L102, used at L136). The resolver looks up the credential by that id, and a learned route borrows the credential of the route it was learned through (resolver.ts#L150-L161, routes.ts#L311-L333).
• Re-pairing only writes the new route's credential. register replaces a route only when it has the same id or the same base URL, and otherwise inserts the new route next to the others (registry.ts#L566-L585, routes.ts#L143-L167). The catalog write stores the credential under the new id only (storageDocument.ts#L136-L160). Nothing updates the other bearer routes. Learned routes the server still reports keep their id, so they keep borrowing from whichever route they were learned through (routes.ts#L268-L274).
• Legacy ids aren't rewritten. The legacy mobile migration still writes bearer:<envId> (migration.ts#L67), and #15467 changed onboarding away from that form. I found no code that renames old ids. One caveat: re-pairing at the same base URL does replace a legacy route, because findRouteToSameAddress compares addresses, not ids.
• Removing a route deletes its credential. removeRoute → routesAfterRemoving drops the route and any learned routes that borrow from it (registry.ts#L946-L968, routes.ts#L340-L361). setRoutesInCatalog then deletes the dropped routes' credentials (storageDocument.ts#L77-L133). So in your reduced repro (pair over LAN, revoke, re-pair over Tailscale, remove the Tailscale route), only the LAN route is left, still holding the revoked token.
• Transient errors win over blocked ones. connectOverRoutes returns transient ?? blocked, and it tries routes that failed the 2.5 s check last (driver.ts#L78-L135). A timeout on an unreachable LAN route is therefore reported instead of the 401 from Tailscale. The doc comment says this is deliberate, so the supervisor keeps retrying a route that may come back.
• Every 401 shows the same message. EnvironmentAuthInvalidError always maps to "The environment credential is invalid." (errors.ts#L121-L126).
• Blocked has no re-pair action. On a ConnectionBlockedError, the supervisor goes to blocked and waits for a signal (supervisor.ts#L928-L944). The presentation layer turns that into an error phase that carries the message (presentation.ts#L51-L56). The shared mobile notice only offers Retry now (EnvironmentConnectionNotice.tsx#L88-L96). I didn't check every mobile screen.

One correction

The client isn't dropping "Session token expired." That text is the server's log annotation (EnvironmentAuth.ts#L695-L705, SessionStore.ts#L105-L116). The 401 body only carries reason: missing_credential | invalid_credential (environmentHttp.ts#L98-L101, http.ts#L96-L112). Showing "expired on " would need a contract change as well as a client change.

Not verified

• I couldn't reconstruct from code exactly how your Tailscale route ended up holding the September token. If it was a route learned through the legacy bearer:<envId> LAN route, re-pairing at the same LAN URL should have replaced that route and deleted its credential. The learned route would then point at a missing credential and fail with "Connection credential … is unavailable", not send the old token. Re-pairing doesn't cascade to learned routes the way routesAfterRemoving does. Can you say whether the Tailscale route was one you added yourself, or one the app learned? And was the September LAN pairing at exactly the same URL as the October one?

Possible fixes (untested sketches)

1. After a bearer pairing, write the new token to every direct bearer route of that environment. Another option is to key direct-route credentials per environment instead of per route, and keep relay and SSH separate.
2. When re-pairing replaces a route, re-point or drop the learned routes that borrow from it, matching what routesAfterRemoving already does.
3. In connectOverRoutes, keep retrying while any route failed transiently, but surface an authentication blocked error from a route that reached the right server.
4. Add an expired/revoked reason to EnvironmentAuthInvalidReason, and show a Pair again action on authentication failures.

Workaround: as you found, remove the whole environment on the phone and pair again.

Related: #13055 (fixed 30-day session lifetime, which triggered this; open PR #13092 is titled as making the lifetime configurable), #15802 (re-pairing at the same address leaves a stale entry), #13072 and #8112 (other "credential is invalid / have to re-pair" reports). #5332 is closed. None of the open PRs I checked change this re-pair or removal path.

Thanks, the correction about the expiry reason is fair: it's only logged server-side, so fix 4 needs the contract change you describe.

On your questions:

• I never added a route by hand. I paired by scanning the QR code, and the other routes (Tailscale included) appeared on their own, so they were learned, not added. When the session lapsed, I scanned the QR code again to refresh the credentials. That only refreshed the LAN route; the learned routes kept the old token.
• The host's records agree: the phone only ever redeemed two pairing codes (6 Sep and 7 Oct), both from LAN client IPs on different subnets, so the two pairings were at different base URLs and the second didn't replace the first route. No code was ever redeemed over Tailscale.

From the user side, this is the core problem: scanning the QR code is how the routes came into being, so scanning it again reads as "refresh this machine". Nothing in the UI suggests the routes hold separate credentials, or that a rescan only updates one of them. I'd expect re-pairing to update every direct route of that environment, which is your fixes 1 and 2. Fixes 1–4 all look right to me.

Confirmed workaround: deleting the environment entirely and scanning the QR code again fixed it. It's now connecting over Tailscale. Removing individual routes and rescanning had not.

Another data point, on stable 0.1.7 (desktop app → remote Linux host).

Setup: T3 Code (Beta) desktop app 0.1.7 on macOS (arm64). It connects to a Linux x64 host that runs t3 serve 0.1.7 as a systemd user service, listening on 0.0.0.0:3773. The host is reachable over Tailscale. The environment has two routes: a manually added Tailscale Serve HTTPS route (https://<host>.<tailnet>.ts.net/), and an auto-found http://<tailnet-ip>:3773/ route.

What happened: About 30 days after pairing, the desktop app stopped connecting. The card said "T3 Code on desktop did not accept this device". Under Details it listed Cause authentication, Route Direct, and Error "The environment credential is invalid.". The only actions offered were Retry and Copy diagnostics, and retrying can never succeed.

Host-side evidence: The client's trace ID shows up in the host's server.trace.ndjson. There were 67 rejected requests, all with the same reason:

Network and discovery were fine. /.well-known/t3/environment returned 200 from the Mac, and both sides report serverVersion 0.1.7 and orchestrationProtocolVersion 2.

Still the case at v0.1.7 and on main: DEFAULT_SESSION_TTL = Duration.days(30) (apps/server/src/auth/SessionStore.ts:429 at v0.1.7). Bearer sessions from direct pairing are never renewed, since renewal exists only for DPoP/relay. The expiry reason is never shown in the UI: mapRemoteEnvironmentError in packages/client-runtime/src/connection/errors.ts maps every EnvironmentAuthInvalidError to the same generic message. So #13055 being closed doesn't help direct-pairing users on stable.

Workaround: create a fresh link on the host with t3 pair --tailscale, remove the environment in the app, and pair again. I removed the whole environment rather than re-pairing in place, to avoid the stale-route problem described above.

Side note: the t3 on the host's PATH was still 0.1.5 while the service ran 0.1.7, which matches #14609. I had to call ~/.t3/runtime/versions/0.1.7/t3 pair directly to be sure the CLI matched the server.

Suggested fixes: (1) Pass the expiry reason through to the client and show "Your login to expired on " with a one-tap re-pair, instead of Retry. (2) Sliding or configurable session lifetime for direct-pairing bearer sessions.

Diagnosed via t3 triage by Claude Opus 5.5 (claude-opus-5-5) running in Claude Code.