Desktop install, QR handoff, and first health checks.
Authentication
Authentication, claims, and machine continuity
FlyDex separates browser account authentication from machine readiness. The phone proves the user identity, the connector proves the machine identity, and the control plane binds the two without exposing local Codex publicly.
Reference map
Public docs sections
Account auth, QR claims, local-connect tokens, and machine continuity.
Thread access, send/resume turns, and remote approvals.
Bridge lifecycle, documented endpoints, and status model.
Threat model, data boundaries, and transport safeguards.
Control plane, connector, and local Codex runtime topology.
Artifacts
Credentials and scopes
| Artifact | Lifetime | Scope | Notes |
|---|---|---|---|
| Clerk account session | Rolling server-side expiry window | User identity | Used for browser account continuity and account-scoped machine access. |
| QR pairing claim | Short-lived, single-use | Single machine handoff | Bound to the desktop session that generated it. |
| Local-connect bearer token | Short-lived | Connector to control plane | Used for authenticated agent status reporting during setup. |
| Machine key material | Longer-lived until rotation | Machine identity | Allows reconnecting the same machine identity without re-pairing every session. |
Phone browser
What the user proves
The phone flow proves the authenticated user session that is allowed to claim the machine. It does not directly talk to the Codex app server.
Connector
What the machine proves
The local connector proves that the desktop is the same machine that owns the saved state, device keys, and readiness signals required for reconnect.