FlyDex technical documentation

FlyDex has three active surfaces. First, the web app provides the public landing page, authentication, QR handoff, thread views, and approval controls. Second, the FlyDex control plane routes authenticated browser traffic, keeps machine registry state, tracks pairing and local-connect lifecycle, and stores the minimal billing and audit metadata needed for continuity. Third, the local connector runs on the same desktop as Codex and is the only component that talks to the local runtime. That split matters: the browser never needs a direct public route to the Codex app server, and the Codex runtime never has to move into a hosted cloud environment just to become reachable from a phone.

The current implementation is designed around operational reliability rather than “remote desktop” semantics. FlyDex is not trying to stream a full screen or expose a general-purpose shell to the internet. It is optimized for the moments that actually stall local agent work: checking whether a thread is still alive, reading the current session state, sending a clarifying prompt, and resolving approvals before a long run sits blocked for hours. That is why the pairing surface is QR-first, the control plane is machine-aware, and the app keeps the session and approval model close to Codex itself instead of pretending the problem is generic device remoting.

Desktop browser -> FlyDex web UI
Phone browser   -> account sign-in + QR handoff
Local connector -> http://127.0.0.1:48163/v1/health and /v1/connect
Control plane   -> session routing, machine registry, approval relay, audit metadata
Codex runtime   -> stays on the local desktop

FlyDex does not publish vanity throughput claims that the product cannot defend. The useful numbers are the ones that affect real operator behavior: how many steps the public workflow requires, how quickly a claim expires, where the helper binds, what the trial window is, and how long a signed-in session remains valid before refresh or sign-out changes the state. The following figures are current product-backed targets or implementation details, not marketing estimates.

The operational center of FlyDex is the thread surface. Once a machine is online, the app can list and read local threads, resume or start turns remotely, and route approval decisions back to the correct session. This is especially useful for unattended or long-running Codex work, where the most expensive failure mode is not a hard crash but a silent pause that waits for a human decision. FlyDex shortens that loop by keeping the state and approval queue reachable from a phone.

High-risk actions still preserve a deliberate approval boundary. FlyDex does not treat a paired device as blanket permission to run everything invisibly. Command execution, file writes, and approval decisions remain explicit UI actions. That is the correct trade-off for a remote control plane: fast enough to unblock work, narrow enough that a lost moment of attention does not become a broad blast radius. The model is closer to “remote steering for a local agent” than “remote shell for a public server.”

These endpoints describe the current FlyDex implementation and are useful for troubleshooting or architecture review. They should be read as operational documentation, not as a promise that every internal control-plane route is a stable public API.

curl http://127.0.0.1:48163/v1/health

# Expected use: local desktop diagnostics only.
# Do not expose this endpoint publicly.

FlyDex is designed so the browser never has to talk directly to a public Codex server. The local connector binds to 127.0.0.1 only, the control plane handles the authenticated relay and machine scoping, and pairing claims expire quickly. For network terminology and transport expectations, the relevant external references are the WebSocket standard in RFC 6455 and the modern TLS baseline in RFC 8446. FlyDex is not claiming a formal certification here; these are the primary standards that define the transport model around secure web and relay communication.

For application hardening, the relevant external checklists are OWASP MASVS and OWASP MASTG. Those references are useful because FlyDex has both browser and mobile-adjacent usage patterns, even though the current control surface is web-first. The practical controls that matter most in FlyDex today are account-scoped machine access, short-lived single-use pairing claims, explicit confirmation for higher-risk actions, redaction of secrets from logs, and at-rest data minimization.

The useful comparison is not brand versus brand. It is whether the control model matches local-first Codex work. FlyDex is opinionated toward secure remote steering of a local agent. Generic remoting, direct tunnels, and hosted workspaces solve adjacent problems, but they make different trade-offs.

1. OpenAI Codex documentation
2. RFC 6455: The WebSocket Protocol
3. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
4. OWASP MASVS
5. OWASP MASTG

For FlyDex-specific storage, pairing, and connector behavior, see the public Trust & Security and Privacy pages.