Desktop install, QR handoff, and first health checks.
Agent control
What the remote control surface can do
FlyDex is deliberately narrower than generic remote desktop tools. The product is optimized around the actions that actually unblock Codex work when the operator is away from the desktop.
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.
Capabilities
Remote actions
| Action | Supported | Why it exists |
|---|---|---|
| List and read local threads | Yes | Operators need state visibility before they can safely intervene. |
| Send or resume turns remotely | Yes | The core remote control loop depends on continuing active work without returning to the desk. |
| Handle approval prompts | Yes | Long-running Codex work stalls when approvals are trapped on the desktop. |
| Expose a raw public Codex endpoint | No | The browser should not talk directly to the local app server. |
| Replace full desktop remoting | No | FlyDex is thread-aware operational control, not a generic screen-sharing product. |
Best use case
Approval-heavy runs
The clearest FlyDex win is avoiding stalled runs during meetings, commutes, or on-call windows where the model is blocked on operator approval.
Intervention model
Machine-aware, not global
Approvals and turns stay scoped to the paired account and machine. This keeps the UI operationally useful even when multiple machines exist under one account.