Allow configuring session lifetime (or sliding expiry) for pairing-issued sessions instead of a fixed 30-day TTL

[jaypopat]

What happened

Feature request, not a bug. I run T3 Code as a background service (systemd user unit) on a home server, reachable only over my Tailnet / reverse proxy. Every client is my own hardware: the desktop Electron app, Chrome, Firefox, and the mobile app.

Every session created through the normal pairing flow (QR code or link) expires exactly 30 days after it was issued, even on devices I use every day. Activity never extends a session, so each device has to be re-paired by hand every month. On a private, single-operator deployment that is unnecessary friction, and I can't configure it.

The request is to make session lifetime for pairing-issued sessions configurable, in any of these ways:

1. A server setting or env var for the default session TTL (e.g. to go beyond 30 days).
2. Sliding expiry: extend expiresAt when an active session connects or is used.
3. Carry a TTL from the pairing grant through to the session it creates (today pairing create --ttl only sets how long the pairing code can be redeemed).

Diagnosis

Checked against the source at tag v0.0.43-nightly.20260922.2096. SessionStore.ts and EnvironmentAuth.ts on main have had no changes since then.

• apps/server/src/auth/SessionStore.ts:423: const DEFAULT_SESSION_TTL = Duration.days(30);, used at :658 as input?.ttl ?? DEFAULT_SESSION_TTL. No config or env override exists.
• The two pairing redemption paths never pass a ttl:
  • Browser: EnvironmentAuth.createBrowserSession (EnvironmentAuth.ts:712-770) calls sessions.issue({ method: "browser-session-cookie", subject, scopes, client }). It has no ttl, and the grant carries none.
  • Desktop and mobile (direct pairing, no DPoP): exchangeBootstrapCredentialForAccessToken (EnvironmentAuth.ts:803-835) only sets ttl (1h) in the DPoP branch. The plain bearer-access-token branch falls back to the 30-day default.
• pairing create --ttl → createPairingLink (EnvironmentAuth.ts:884-895) → PairingGrantStore.issueOneTimeToken (PairingGrantStore.ts:385-389). That TTL only sets when the pairing credential expires. It is not stored on the grant for use when the session is issued.
• SessionStore.markConnected (SessionStore.ts:566-600) only writes last_connected_at. No code path updates expires_at for a live session (persistence/AuthSessions.ts has no expiry-updating statement).
• The only way to get a custom lifetime today is t3 auth session issue --ttl (EnvironmentAuth.issueSession, :932-942). It mints a raw admin bearer token outside the pairing flow, so the browser and mobile pairing UIs can't use it.

Steps to reproduce

1. Run the server (t3 serve or the background service) and pair a browser, the desktop app, and the mobile app using the normal QR code or link.
2. Use each device daily.
3. Exactly 30 days after pairing, each client is signed out and has to be paired again. last_connected_at updates each day, but expires_at stays at issued_at + 30d.

Version

0.0.43-nightly.20260922.2096

Environment

Linux x64 (Debian, kernel 6.1), Node v26.8.2, server run as a systemd user service behind Tailnet/reverse proxy; clients: desktop (Electron), Chrome, Firefox, mobile app

Evidence

# auth_sessions rows (read-only query, identifiers/IPs omitted)
method                  device   surface  issued_at                 expires_at                last_connected_at
bearer-access-token     mobile   mobile   2026-08-18T18:04:20.620Z  2026-09-17T18:04:20.620Z  2026-09-13T10:35:29.265Z
bearer-access-token     desktop  desktop  2026-08-18T17:58:40.540Z  2026-09-17T17:58:40.540Z  2026-09-16T21:12:22.277Z
bearer-access-token     desktop  desktop  2026-08-18T17:53:48.559Z  2026-09-17T17:53:48.559Z  2026-09-16T21:14:55.888Z
# re-paired after expiry:
browser-session-cookie  desktop  web(FF)  2026-09-22T09:43:46.778Z  2026-10-22T09:43:46.778Z  2026-09-22T11:33:04.843Z
browser-session-cookie  desktop  web(Ch)  2026-09-22T09:54:53.810Z  2026-10-22T09:54:53.810Z  2026-09-22T10:10:45.786Z
bearer-access-token     desktop  desktop  2026-09-22T09:42:49.693Z  2026-10-22T09:42:49.693Z  2026-09-22T11:30:18.159Z
bearer-access-token     mobile   mobile   2026-09-22T11:34:37.230Z  2026-10-22T11:34:37.230Z  2026-09-22T11:42:51.310Z

Sessions last used 1–4 days before expiry still expired at exactly issued_at + 30d.

Related issues

#9884 (Session TTL is inverted vs credential strength: DPoP 1h, bearer 30d). Related, but it pushes the other way and asks for an explicit, shorter bearer TTL. Not a duplicate: this issue asks for the pairing-issued session lifetime to be configurable by the operator and/or to slide with activity. A configurable TTL, set explicitly at the pairing call sites, would address both issues: a short default for exposed deployments, and a longer or sliding lifetime for private single-operator ones.

Fix applied or workaround

None applied. The only workaround is re-pairing every 30 days. t3 auth session issue --ttl doesn't help, because the browser and mobile pairing flows can't redeem the token it mints.

Filed by

Claude Code (claude-opus-5) via t3 triage

[juliusmarminge]

Triage

Confirmed as a real product gap, not a misread of the current design. Pairing-issued sessions have a fixed absolute 30-day TTL with no operator override and no activity-based extension.

What the code does today

• Default lifetime is hardcoded in SessionStore:
  • DEFAULT_SESSION_TTL = Duration.days(30)
  • issue uses input?.ttl ?? DEFAULT_SESSION_TTL
• Neither pairing redemption path passes a session TTL:
  • Browser: EnvironmentAuth.createBrowserSession → sessions.issue({ method: "browser-session-cookie", ... })
  • Desktop/mobile (non-DPoP): exchangeBootstrapCredentialForAccessToken only sets ttl: Duration.hours(1) on the DPoP branch; plain bearer-access-token inherits the 30-day default
• pairing create --ttl only controls pairing-grant expiry in PairingGrantStore.issueOneTimeToken, not the session created on redeem
• markConnected / AuthSessions.setLastConnectedAt update last_connected_at only; there is no expires_at update path
• Session tokens embed absolute exp in signed claims, and SessionStore.verify enforces that claim — so “slide the DB row” alone would not keep a stored bearer/cookie alive
• There is no ServerConfig / env knob for session TTL. The only custom-TTL path is t3 auth session issue --ttl, which is outside the normal pairing UIs

This matches the reporter’s auth_sessions evidence (expires_at = issued_at + 30d while last_connected_at keeps moving).

Related

• Session TTL is inverted vs credential strength: DPoP gets 1 hour, plain bearer gets 30 days #9884 asks about the inverted DPoP (1h) vs bearer (30d) choice and, in comments, for durable-until-revoke direct clients. Same root TTL surface; not a duplicate — that issue is about credential-strength / renewal model, this one is about making pairing-session lifetime operator-configurable (and optionally sliding).

Suggested direction

Product call first (absolute longer TTL vs sliding vs durable device auth + rotated short tokens). Smallest useful change after that: a server setting/env for default pairing-session TTL, applied explicitly at both pairing issue call sites, plus user/ops docs. Sliding expiry or auto-refresh is a larger follow-up because of the signed exp claim.

Labels: enhancement, accepted, via-triage (remove needs-triage)

[Tylerjet]

Previously paired desktop environments reject credentials while all apps remain running

What happened

Two remote environments that previously worked now show this error in the macOS T3 Code desktop app:

Connection failed: The environment credential is invalid.

The user reports that the local app and the app instances on both remote PCs remain running. They expected those connections to remain usable without manually pairing again.

Diagnosis

Confirmed: both remote servers answer discovery requests successfully, then reject the desktop client's bearer-authenticated WebSocket-ticket request with HTTP 401 and invalid_credential. The client maps that response to the displayed message.

The retained traces already show failures while the desktop was on .2083, before its update to .2110. The authentication implementation did not change between those releases. No newer published fix was found in the release listing and main comparison checked during triage on September 22, 2026.

Possible explanation, not confirmed for these sessions: the fixed lifetime of directly paired bearer credentials described in #13055. Source at release commit aff9318bf46beaf05cc7155b428d3f0b8711efd2 shows:

• SessionStore defaults to 30 days and embeds an absolute expiry in the signed token. Activity updates last_connected_at, not expiry.
• Pairing exchange inherits that default for bearer credentials. The direct client stores and reuses the issued token without automatic renewal.
• Connection-runtime documentation explains that expiry does not close an established socket, but new HTTP requests and socket upgrades still need valid credentials. An app can therefore stay open while a later reconnection encounters expiry.
• Error mapping reports authentication rejection as the generic invalid-credential message.

The affected sessions' issue/expiry/revocation timestamps and remote verification errors were not available. Expiry cannot yet be distinguished from revocation, missing session records, or signature failure. The event that triggered reconnection is also unknown. No credential was decrypted, and the secrets directory was not read.

Documentation gap

The user was unaware that a paired device could require pairing again after a fixed lifetime. The installed-release documentation and the current main README and remote-access guide were checked on September 22, 2026:

• The README links to the repository's user guides but does not disclose the 30-day pairing-session lifetime. The GitHub wiki URL redirects to the repository home.
• The direct-pairing guide explains future reconnection but does not state the 30-day absolute lifetime, lack of renewal with activity, or eventual need to pair again.
• The same guide briefly mentions expired credentials in connection management and explains renewal for T3 Connect. It does not explain that directly paired connections have a different renewal limitation.

Regardless of whether expiry caused these particular failures, the direct-pairing guide should disclose the lifetime and recovery steps. An expiry-specific client message would also make recovery easier than the current generic invalid-credential message.

Steps to reproduce

Reported sequence, not a deterministic reproduction from fresh state:

1. Pair a macOS desktop client with two remote environments over private-network HTTP endpoints.
2. Use the connections successfully and keep the local and remote apps running.
3. Subsequently observe both environments fail to connect with the error above.

Original pairing dates and the precise transition from working to failing have not been established. No fresh authenticated reproduction was run during triage.

Version

• Desktop: 0.0.43-nightly.20260922.2110 at triage; failures also recorded on 0.0.43-nightly.20260922.2083.
• Both remote servers: 0.0.43-nightly.20260922.2083.

Environment

macOS client, Darwin 25.5.0, arm64. Triage CLI used Node v26.8.2 and was launched with npx t3@nightly triage. Two remote PCs; their exact OS versions and server launch mechanisms were not independently verified. Direct bearer connections to private-network HTTP endpoints on port 3773.

Evidence

Sanitized summary of retained client trace spans; hostnames, IP addresses, identifiers, credentials, and home paths omitted:

2026-09-22, client .2083
Remote A: discovery GET -> 200; websocket-ticket POST -> 401
First retained ticket rejection: 12:36:13.103500 UTC
Remote B: discovery GET -> 200; websocket-ticket POST -> 401
First retained ticket rejection: 12:40:50.382700 UTC

2026-09-22, client .2110
Both remotes: discovery GET -> 200; websocket-ticket POST -> 401
EnvironmentAuthInvalidError:
  The environment rejected this client's credentials (invalid_credential).
ConnectionBlockedError:
  The environment credential is invalid.

Related issues

• #13055: fixed 30-day pairing-session lifetime and missing activity-based renewal. Possible match; this report does not independently confirm expired credentials.
• #13072: recurring connection loss recovered through re-pairing. Similar symptom; no service-update failure is established here.

This is intended as additional evidence and user impact on an existing discussion, not a claim of a new confirmed root cause.

Fix applied or workaround

None applied. Fresh pairing links from each host were proposed, but have not been generated or redeemed. No authentication state, database records, or application source were changed.

To resolve the remaining uncertainty, inspect only the affected remote sessions' issued_at, expires_at, last_connected_at, and revoked_at, plus the redacted server-side verification error corresponding to a failed ticket request.

Filed by

Prepared by Codex (GPT-6) via t3 triage.

[allanben13]

+1 — same kind of deployment here: t3 serve as a systemd user unit, reachable only over the tailnet, with the desktop app on two Macs and the iOS app.

On day 30 our desktop clients lost access without warning, and from the client side it looked like a server outage rather than an expired pairing. We worked around it on desktop by provisioning a bearer session issued with t3 auth session issue --ttl, but the iOS app can only redeem a pairing code, so for phones option 2 (sliding expiry on connect) or option 3 (TTL carried by the pairing grant) is the only real fix.

Related: after re-pairing, our desktop app still did not reconnect because the environment had been switched off in the meantime — reported separately.

[RoniEstein]

We hit this too: a single-operator t3 serve reachable only over Tailscale, used from the iOS app, the desktop app on two Macs, and a browser. Every device lost access on day 30 with no warning.

I'd like to propose option 2 (sliding expiry) and offer a PR if it's the direction you'd accept. We have a working prototype (+544/−5, about half of it tests) that we haven't submitted. Here's the design so you can say yes or no before anyone spends review time on it.

Server

• New authenticated endpoint that renews the current bearer session. It keeps the same session id, re-signs the token with a new exp, and sets auth_sessions.expires_at in one guarded UPDATE … WHERE revoked_at IS NULL AND expires_at > now. That covers your point that the signed exp claim means moving the DB row alone can't keep a token alive.
• Renewal is only allowed in the last 7 days before expiry. Earlier calls get session_renewal_not_due.
• Only bearer-access-token sessions can renew. Browser cookie sessions and the 1-hour DPoP/relay path are unchanged (session_renewal_not_supported).
• Revoked or already-expired sessions can't renew, so revocation stays authoritative, and a device unused for 30 days still expires.

Client (packages/client-runtime)

• When a saved bearer environment is within the 7-day window, the authorization layer calls the endpoint and stores the new token. Desktop, web and the Expo app get this without per-app changes.

Tradeoffs we know about

• The previous token stays valid until its original exp, so for up to 7 days two tokens work for one session. We could close that by binding verification to a per-session issued-at or a token generation counter, if you'd prefer.
• Sliding expiry means a leaked token can be kept alive by whoever uses it. Revoking the session is the control, same as today.

Relationship to #13092: they're compatible. A configurable T3CODE_SESSION_TTL would set the lifetime each renewal grants. #13092 alone moves the cliff further out without removing it, and phones can only redeem a pairing code, so they can't use the t3 auth session issue --ttl workaround.

If you'd rather go with option 3 (TTL carried by the pairing grant) or a different renewal shape, we'll follow that and drop this. The prototype was written with Codex. We'd rebase it onto current main and review it before opening anything.

[callmemorgan]

+1 on this issue. I'm not sure what the best solution is, but having to have codex ssh around and copy in some new pairing urls ain't it.

[cal88]

Another data point for the product decision.

Setup: T3 Code 0.0.45 as the background service (systemd user unit) on a home server. It listens on 127.0.0.1 only and is published to my tailnet with Tailscale Serve. One operator, and every client is my own device: the Windows desktop app and browsers so far, Android phones next.

Every device paired on the same day expires on the same day. t3 auth session list shows expiresAt = issuedAt + 30 days for each session, whatever its lastConnectedAt. Recovery needs a shell on the host: with the server bound to loopback behind Serve, the web UI doesn't offer Create link, so a new link has to come from t3 pair --tailscale. If the sessions lapse while I'm away from home, the phone stays locked out until I can reach the host.

For a setup like this, an operator-set lifetime (#13092's T3CODE_SESSION_TTL) would be enough. Sessions stay revocable with t3 auth session revoke, and keeping the 30-day default leaves exposed setups as they are. Sliding expiry or durable device authorization would be welcome later, but the setting alone fixes the day-to-day problem.

[TinBane]

Another data point: a single-operator setup with the T3 Code Nightly desktop app on macOS, the iOS app over LAN and Tailscale, all my own devices.

The phone's session expired on day 30 with no warning, and nothing in the app said so. It showed a connection timeout, even after reordering routes and relaunching the app several times, because an unreachable LAN route masked the 401. Only after I removed that route did it say "The environment credential is invalid." The server logged the reason as Session token expired., but that never reached the UI, so I had no idea it had expired and assumed it was an app bug. As others have said, the iOS app can only redeem a pairing code, so t3 auth session issue --ttl doesn't help on the phone.

Re-pairing didn't cleanly recover it either. Since environments got multiple routes (#15467), re-pairing replaces the login only on the route it pairs through, so the expired login stayed on the Tailscale route and became the only one left once I removed the LAN route. I've filed that separately as #17014.

+1 for sliding expiry (option 2). Even without it, the client could show "login expires on " and a one-tap re-pair when the server reports an expired session, which would turn day 30 into a 10-second fix instead of a debugging session.

[jason5545]

A data point from a fork that ships option 2 (sliding expiry). It has run since Oct 20 on our own server, with the macOS desktop app, Android and browsers as clients.

• When a session connects with 29 days or less left, its stored expires_at moves to now + 30 days. That happens where the server already records a connection (markConnected), in the WebSocket ticket handler for browser cookies, and when an open connection's session falls due, instead of sleeping until the expiry read at connect time. At most one write per session per day.
• SessionStore.verify checks the stored expires_at instead of the token's exp claim. Renewing the row alone is not enough: a bearer token is rejected at its claim before it can get a WebSocket ticket. The claim is still decoded and validated, and it equals the stored expiry until the first renewal, so unrenewed sessions behave as today.
• Browsers drop a cookie at the Expires it was set with, so the ticket handler re-sets the session cookie with the new expiry.
• Never renewed: revoked or expired sessions (the UPDATE repeats both guards, so a revocation that races a renewal still wins), T3 Connect (DPoP) sessions, sessions issued shorter than 30 days, and MCP client sessions (we give those a lifetime chosen when the approval code is made, see Keep an unattended outside agent signed in at Full access past 30 days #19460).
• No new endpoint, no client change and no migration. Sessions issued before the change renew on their next connection.

Commit with tests: jason5545@34194ae104 (current version: sessionRenewal.ts).

The trade-off is that a bearer token's exp no longer bounds it: a leaked token stays valid as long as something keeps connecting with it, until it is revoked in Settings → Connections. RoniEstein's endpoint-based design above, which re-signs the token with a new exp, keeps the claim honest at the cost of a client change. This one needed none.

[sg448]

I have the same setup as several people here: an iPhone paired directly with my Mac over Tailscale Serve. Its session runs out 30 days after pairing however often I use it, and since the app can only redeem a pairing code, the only fix is pairing again. I'd like to propose a renewal design that answers the objection that ended desktop-session renewal in #16274.

Where things stand, at main @ d2c4403

• A directly paired client gets a bearer-access-token session with the 30-day default, since only the DPoP branch of the token exchange sets a ttl. verify rejects the token at its signed exp claim, so extending a session means giving the client a new token.
• feat(auth): desktop-local sessions renew without the bootstrap token #16274 let a desktop session trade itself for a fresh one, revoking the old one, and was dropped after adversarial review: "Renewal let a stolen desktop session renew itself indefinitely." The desktop got rotating bootstrap tokens instead (feat(desktop): the renderer's bootstrap token rotates every 12 hours #16275), but a paired phone has no secret besides its bearer.
• Both designs above share that property. RoniEstein's leaves the previous token valid until its original exp, and jason5545's makes the stored expires_at authoritative. Either way a copied token keeps renewing as long as someone uses it, and nothing notices that two parties hold it.

Proposal: rotation with reuse detection

This is refresh-token rotation as described in RFC 9700, section 4.14.2. Section 2.2.2 of the same RFC says a public client's refresh tokens must be either sender-constrained or rotated; this is the rotated option.

1. When a client connects with a bearer session past half its life, it trades the token at /oauth/token in a token exchange whose subject is the live session: a second subject_token_type beside the bootstrap one. The server issues a new session with the same subject, scopes, and client label.
2. The old session is revoked when the new one is first used, not when it is issued, so a response lost while the phone is suspended doesn't strand it. SessionStore already has the swap: replaceSessionId, which a browser uses when it pairs again. What's new is deferring it to the first use.
3. Presenting a token that has already been replaced revokes its successor too. If a copied token and the real phone are both in use, one of them will present a replaced token, and the session ends for both: the phone has to pair again, and the copy is dead. A copy can only keep renewing if the real device stops connecting.
4. The bounds stay as they are: a device unused for 30 days still expires, and a revoked session can't renew. Only bearer sessions issued from a pairing link renew; DPoP sessions and the desktop's own sessions keep their current paths. Browser cookie sessions could take the same rule later, but I'd leave them out to keep the change focused.

What this doesn't cover: if the phone itself is stolen, the thief holds the only live copy and can keep it alive until the session is revoked on the host, where today it would lapse within 30 days. An absolute cap counted from the original pairing, such as a year, would bound that if you want one.

Alternative: bind direct pairings to a key

This is the other option RFC 9700 allows. The client generates a proof key when it pairs, using the DPoP signer the clients already use for T3 Connect. The pairing becomes a durable device grant bound to that key, and the client exchanges a DPoP proof for one-hour tokens, as Connect does. A token copied off the device is useless without the key, which answers the stolen-token objection completely and removes the long-lived unbound bearer that #9884 is about, as seanpianka suggested there. It's the bigger change: a new kind of durable grant on the server, and non-exportable key storage in each client.

Which of these would you accept? I'm happy to build either one, with server and client tests, once you've agreed the direction and scope.

[jason5545]

Follow-up to my comment above: sg448's objection holds for the design I posted, so the fork changed it on Oct 27. A session now renews only when the connection comes from the device it was issued to, which on a tailnet the network layer can already tell us.

• The fork pairs a device over Tailscale without a code (tailscale whois on the connection must name an untagged node of the host's owner), and that session records the node's StableID as its subject. When the session falls due, the server runs whois on the request's source and renews only if it names the same node. A copied token used from anywhere else keeps working until its deadline and then stops, and the server logs the declined renewal.
• A session paired with a code takes the node's subject the first time the owner's untagged device renews it over the tailnet, on a host with Tailscale pairing on. From then on the same rule applies, and revoking it also stops that node from pairing without a code.
• Nothing else renews any more: sessions used only over the LAN, CLI-issued ones, and code-paired ones on a host without Tailscale pairing. They run out 30 days after pairing or their last renewal, as on upstream today, and the client then pairs again over Tailscale when the host allows it.
• whois runs only when a renewal is due, at most once per session per day, never per request: the clients also reuse the credential over LAN routes, where whois has nothing to say.
• Separately, the server now reports session_expired and session_revoked instead of folding both into invalid_credential, so the client can say "The sign-in expired. Pair this device again." or "This device was signed out." That is the generic message Tylerjet hit above, and it might be worth taking on its own.

This is a data point for setups on Tailscale only: the device identity comes from Tailscale's node key, which upstream's direct pairing doesn't have. For upstream, sg448's key-bound alternative looks like the general form of the same idea, with the DPoP key playing the part the node key plays here. The gap is the same as theirs: a stolen device keeps renewing until it is revoked on the host.

Commit: jason5545@ffb2744f85 (sessionRenewal.ts; the node check is renewalSubject in TailscalePairing.ts).

[sg448]

An update: I built the key-bound version on a fork (with main up to dd14848), and it now runs on my own Mac and iPhone.

• The phone creates a P-256 key in its Secure Enclave and pairs with a DPoP proof from it at /oauth/token, which binds the session to the key. A key-bound direct pairing (subject one-time-token) keeps the full 30 days instead of Connect's hour; Connect's grants are unchanged.
• Renewal is a token exchange at /oauth/token with the live access token as the subject and a proof from the same key. The session keeps its ID, and its stored expires_at moves forward in a guarded update, so a revocation that races a renewal wins. A copied token can't be used or renewed without the key, which answers the objection from feat(auth): desktop-local sessions renew without the bootstrap token #16274; the gap left is the phone itself being stolen and unlocked, where revoking it is the control.
• The client renews at half the token's life, both when it connects and while a connection stays open, so a phone in use never lapses and one unused for 30 days still does.
• SessionStore.awaitInvalidation read the expiry once at the upgrade and closed the socket then; it now reads the stored expiry again, so a renewal doesn't drop an open socket.
• There's no migration. Clients pair with a key only where the server advertises a new directPairingRenewal capability, and the key's details go in an optional field of the saved credential, so older clients still read their catalog.

Testing it live with a 5-minute lifetime turned up one thing worth knowing for anyone building this. The client counts the lifetime from when the token arrives, in whole seconds (expires_in), so its half-life lands a fraction of a second before the server's, and an exact check on the server hands the token back unrenewed. I now accept a renewal from half-life less 5% of the lifetime (at most 5 minutes), which also absorbs a small clock difference, and the client retries a "not yet" after a tenth of the time left. After that, renewal ran on schedule with no reconnect, the socket outlived the original expiry, and an app reopened past half-life renewed before connecting.

One finding along the way: the web front of vp run dev --share rewrites the ticket request on its way to the server, so a DPoP-bound client fails there with request_mismatch. I tested through a direct Tailscale Serve address instead.

The fork is private, but I'm happy to turn this into a pull request here if you'd accept this direction. Android would need the same from its Keystore, and web and desktop clients would stay on bearer pairing unless they get a hardware-backed key too.

[architpai]

We hit this too. I run T3 Code on three hosts (a MacBook, a Mac mini and a Linux box), all reachable only over my tailnet, and use them from the iOS app and from each other's desktop apps. Every pairing expires 30 days after it was issued, regardless of daily use, and each one on a different date. Today my iPhone suddenly showed "The environment credential is invalid" for the MacBook. The server log said Session token expired., but the app didn't.

My current workaround is to have a coding agent SSH into each host, run t3 auth pairing create, and send me a QR code to scan. It works, but it's tedious, and with several hosts something is always about to expire.

For single-operator setups where the server is only reachable over Tailscale (loopback behind Tailscale Serve, or tailnet-only), I'd love an operator-set session lifetime that can also be "never expires", e.g. T3CODE_SESSION_TTL=never, keeping the 30-day default for everyone else. The tailnet is already the access control in this setup, and revoking a device with t3 auth session revoke still works if a device is lost. Sliding renewal would also solve it, but even the simple setting would remove almost all of the pain.

---

Posted by Claude Opus 5.5 on behalf of Archit Pai.

[areidyOTH]

Another Android data point: I use the T3 Code Android app (2.2.0) with three Linux hosts over Tailscale HTTPS. Today the app could not connect to any of them. Two showed “did not accept this device”; the expanded diagnostic said “The environment credential is invalid.” The third showed a timeout on an automatically learned direct route.

The phone’s Tailscale VPN was connected, all three hosts were reachable, and fresh pairing codes restored all three connections. The newly issued mobile sessions each expire exactly 30 days after issue. We did not recover the old sessions’ expiry/revocation records, so I cannot prove expiry caused this particular incident.

For my setup, an opt-in six-month lifetime for sessions created through normal phone pairing would already solve most of the friction. Keeping the 30-day default and allowing individual revocation would be fine. Device-bound automatic renewal would be even better, including Android support, without requiring T3 Connect.

Please also show the session expiry date and distinguish expired credentials from revoked/invalid ones in the app. A generic rejection or a timeout from another route makes this unnecessarily hard to diagnose.

Posted by Codex on my behalf.