[Bug]: Stable t3 pair prints an unusable token for a running Nightly/V2 server #15492

Before submitting

• I searched existing issues and did not find a duplicate of this specific failure.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run T3 Desktop Nightly 0.0.46-nightly.20261004.2644 on macOS with its existing T3 home after V2 migration. The live environment descriptor reports orchestrationProtocolVersion: 2.
2. On the same Mac, run npx t3 pair. In the observed setup this selected stable CLI 0.0.45. To keep the CLI version deterministic, use npx --yes t3@0.0.45 pair.
3. Use the freshly generated pairing URL with the live server before the token expires. The command prints a QR, URL, token, and expiry as if pairing can succeed.
4. The receiving client reports an invalid pairing token.

Expected behavior

The CLI should generate a credential usable by the discovered running server, or reject an incompatible server/CLI pairing before opening or writing a database. A channel/protocol mismatch should give an actionable explanation and a command using the matching server version.

Actual behavior

The stable CLI discovered the running Nightly server but issued its link in V1 state.sqlite. The running Nightly server used V2 statev2.sqlite and could not see that credential. The command appeared successful; the later invalid-token message did not identify the version/database mismatch.

Read-only database metadata checks located the stable command's new link in state.sqlite and showed no corresponding new link in statev2.sqlite. Issuing a replacement with the matching Nightly CLI created a link in statev2.sqlite and pairing succeeded. The existing HTTPS discovery endpoint continued to reach the intended protocol-2 server.

Impact

Major degradation: the default npx pairing command appears to work but cannot pair to an already-running V2 host. A matching-version command provides a workaround.

Version or commit

Pairing CLI: t3 0.0.45 (stable).
Running Mac desktop/server: 0.0.46-nightly.20261004.2644, orchestration protocol 2.
Working replacement CLI: 0.0.46-nightly.20261004.2644.
Observed October 4, 2026.

Environment

macOS T3 Desktop, existing user T3 home containing both V1 and V2 databases, CLI invoked via npx. Tailscale provided private HTTPS access. The owner confirmed successful Safari pairing and then native iPhone pairing after the workaround. No separate development worktree server was involved in this diagnosis. Exact macOS, Node, and iPhone build numbers were not captured.

Logs or stack traces

No stack trace was captured. Pairing URLs, credentials, hostnames, account identities, and network addresses are omitted.
Nonsecret metadata from the original stable link:

• state.sqlite: created_at 2026-10-04T04:49:08.849Z; expires_at 2026-10-04T04:54:08.849Z.
• statev2.sqlite: no corresponding new link at that time.
  Replacement generated by the matching Nightly CLI:
• statev2.sqlite: created_at 2026-10-04T04:54:00.561Z; expires_at 2026-10-04T05:09:00.561Z.

Workaround

Run on the machine hosting the already-running server:

npx --yes t3@0.0.46-nightly.20261004.2644 pair --tailscale --ttl 15m

Use the exact running server version for later setups. npx --yes t3@nightly pair --tailscale also worked when the nightly tag matched the installed server. Use a fresh token per receiving app/browser; opening it in Safari authorizes Safari separately from the native phone app.

Related context

#10516 is related to the pairing CLI opening an installed server's database using another runtime's schema, but concerns development-worktree migrations rather than stable/V2 tokens being written to different databases.
#10516

V2 migration documents separate state.sqlite / statev2.sqlite databases:
#14871

The observed Nightly pairing implementation discovers the running server and derives storage paths before issuing the token:
https://github.com/pingdotgg/t3code/blob/v0.0.46-nightly.20261004.2644/apps/server/src/cli/pair.ts