Building Reallexi Connect: Reallexi Connect is a proprietary, consent-based remote-display and remote-control platform

Reallexi Connect is out now on Web, Windows, VS Code. This is how it got made: the decisions, the pipeline, and what I would do differently.

What it is

See and control your own Windows, macOS or Linux computer from any device you are signed in on, with a host that always shows the session and can stop it.

no session limit, no limit of control, 60 fps easy to play games on host, all clean JS / Electron / Service, unlimited, optional service

Decision

Use documented public platform APIs and normal consent/security dialogs only. Every capability is feature-detected and classified as implemented-and-tested, experimental, view-only, unsupported by public API, blocked by code signing, blocked by store policy, or blocked by test hardware. The UI disables unavailable actions with a factual explanation. No TCC, UAC/secure desktop, lock screen, sandbox, AccessibilityService policy, anti-cheat, antivirus, firewall, store, or driver-signing bypass is permitted.

Windows virtual displays require the documented Indirect Display Driver and a production-signed package tested on Secure Boot hardware. macOS production needs signing/notarization; iOS cannot claim arbitrary system input; Android capture retains MediaProjection/foreground visibility; Wayland follows portal/compositor capability; browser host control requires a native

Checkout unreachable for email-link and Google accounts; devices page rail (2026-09-11)

• POST /billing/stripe/checkout required recent step-up, but email-link and Google sign-ins never carry step-up and every access-token refresh drops it, so "Choose plan" answered "Authenticator verification required" for most accounts with nothing to click. The server now requires only authentication to start a checkout (Stripe authenticates the payment; the plan changes only on a signed webhook). live-stripe.test.ts now starts its checkout with a refreshed, non-step-up token; control plane typecheck and 167/167 tests pass under Node 24. Not yet live: shipping it needs the full production release (npm run publish -- -InventoryFile ...), whose inventory is not on this machine.
• Until then the web client handles the refusal: Billing opens a "Confirm it's you" panel (passkey or authenticator code, then straight on to Stripe; otherwise a pointer to Account security). Verified with a Playwright run against a mocked step_up_required.
• Devices page: the setup rail's first card was position: sticky and slid over the cards below it on scroll (now static; a scrolled-overlap probe reports none at 1440/390px); the trusted-approval card had no styles at all - its checkboxes are now selectable bordered rows, its selects and headings styled, and its rules one line with Revoke beside them. Card headings with only a title block keep the description under the

Native service implementation and physical testing (2026-10-22, in progress)

The working tree now contains a real SCM/LocalSystem service, protected runtime and private state installation, first-install protected-key enrollment, mandatory Windows setup/repair routing, desktop-bound capture and input helpers, and visible local Pause/Stop/duration/emergency controls. Native input verifies the signed ticket through agent-core before executing events. The retired elevated-user-task option stays disabled.

The first local development installation (1.0.68) registered and connected successfully on GodOfGaming3, using a new protected service identity. A real authenticated WebRTC probe received no video; secure-desktop functionality is not accepted from service registration or unit tests. That test also found a missing Windows PowerShell search directory in the restricted worker environment.

The subsequent 1.0.69 installation exposed an executable sharing violation during update and rollback. Version 1.0.70 changes the service and helper executables to immutable paths inside each protected runtime version, waits for the previous service process to exit, stages complete runtimes before switching, records a source digest for exact retries, and restores the previous SCM executable path/configuration on failure. Physical testing of that implementation is ongoing; no rollback, secure-desktop, or production claim is made yet. Signing, real desktop transitions…

Stage 3 — supported platform implementations

Implement independently behind the same policy contract:

• Windows WFP plus reviewed tunnel runtime and signed installer/update/uninstall;
• macOS Network Extension with correct entitlement, Developer ID/App Store packaging and notarization;
• iOS/iPadOS Network Extension with physical-device and store review;
• Android foreground VpnService with system consent/revocation and OEM matrix;
• Linux namespace/cgroup/firewall isolation with signed distro packages.

For each claimed OS/architecture/version, repeat the Stage 2 hostile-process, network-conflict, lifecycle, upgrade/rollback/uninstall, accessibility and hardware tests. Systems without a conforming native adapter continue with browser/native WebRTC direct or explicitly accepted TURN fallback.

Exit evidence: independently reviewed source, pinned dependencies, license approval, SBOM/provenance/vulnerability scans, signed/notarized packages, secure update and clean uninstall, and the published supported-version

Latest changes

Changelog

All notable changes to RealLexi Connect are recorded here. A version entry describes the implemented and locally validated source revision; public Pages/Milan activation and native signing evidence are recorded separately and are never inferred from the changelog.

What is next

It is live at https://connect.reallexi.io. If you have shipped something similar, I would like to hear what you would have cut.