[Bug]: Upgrading the server invalidates existing pairings ("The environment credential is invalid" on the phone), a newer desktop refuses an older server, and nightlies remove RPC/HTTP surfaces and rename the database without a release note #21375

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: After Update i get asked for a local remote to pair with this environment #20871 (needs more info: asked to pair again after an update) and [Bug]: Saved connections no longer decrypt on Linux and macOS after the Alpha → Beta rename #20906 (saved connections no longer decrypt after the rename) look like the same family; this report adds a reproducible case and the headless angle.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Pair the iOS app with a headless server (t3 pair --tailscale-serve-port 8443) on nightly A.
2. Upgrade the server to nightly B and restart it.
3. Open the thread list on the phone.
4. Separately: update the desktop app before the server.

Expected behavior

• A pairing survives a server upgrade. The credential format and signing secret are stable across nightlies.
• Client/server skew of one nightly is tolerated, or the client offers to keep using the older server read-only.
• A nightly that removes an HTTP route, changes the command shapes or renames the state database says so in its release notes.

Actual behavior

• 2026-09-26, 0.0.43-nightly.20260924.2200 → 0.0.43-nightly.20260926.2282: the phone showed "The environment credential is invalid". Only a new t3 pair fixed it.
• 2026-10-04: the desktop said "The new t3code client can't connect to the server because it's too new", which forced the server upgrade to 0.0.46-nightly.20261004.2657.
• That upgrade (orchestrator V2, feat(orchestrator): introduce new orchestrator #2829) removed POST /api/orchestration/dispatch (every external dispatch answered 404; 53 headless threads sat idle until we rewrote our client for the /ws RPC orchestration.dispatchCommand), moved the read model to statev2.sqlite and froze state.sqlite at 24.7 GB on disk. Nothing in the release mentioned either.
• The compiled binary path also changed (npx t3 → @t3code/t3-linux-x64/t3), and since 2026-10-17 the @t3code/t3-linux-x64 package is no longer published to npm (404), so the only install path is the GitHub release tarball.

Impact

Major degradation or frequent failure (each occurrence cost the whole fleet an outage of 30–60 minutes)

Version or commit

0.0.43-nightly.20260926.2282 (pairing), 0.0.46-nightly.20261004.2657 (API and database), 0.1.1-nightly.20261017.3238 (npm package gone).

Environment

Linux (Ubuntu, kernel 7.0.0-38-generic), compiled @t3code/t3-linux-x64 binary (Node.js v26.8.2 in crash traces), t3 serve --host 127.0.0.1 --port 3773 --base-dir ~/.t3 as a systemd --user service, headless; Tailscale serve in front; clients: macOS desktop app, iOS app, web. 40–50 live threads at a time over 8 Claude Code instances (claudeAgent), 3 Codex instances and ACP providers (Grok CLI, OpenCode with GLM). ~16,900 threads in statev2.sqlite (40.4 GB). Threads are created, woken and stopped by our own tooling over the /ws RPC (orchestration.dispatchCommand), not by a human in the UI.

Running build: 0.0.46-nightly.20261008.2819 with two local server patches (GitHub PR-sync cadence, Grok multi-task wait). Each draft says whether the patch touches the reported area. Clients: iOS app and macOS desktop app, both current at the time.

Logs or stack traces

# phone, after the server upgrade
The environment credential is invalid
# desktop, before the server upgrade
The new t3code client can't connect to the server because it's too new
# headless client, after 2657
dispatch ... rejected http=404

Workaround

Re-pair after every upgrade; upgrade the server the moment the desktop app updates; a timer of ours checks the running binary for our fork patches and for the RPC shape before the fleet trusts it.