Remote Dashboard
The dashboard exposes a desktop Remote button. The tunnel is created only when the
user enables it at runtime; normal ao start remains local-first.
A practical review artifact for the current branch: what V1 ships, why it is enough for first release, which security concerns are real, and what should move to V2.
The dashboard exposes a desktop Remote button. The tunnel is created only when the
user enables it at runtime; normal ao start remains local-first.
Public access requires configured credentials. Local loopback dashboard access remains frictionless unless the request carries a real external proxy address.
Terminal WebSocket traffic routes through the dashboard origin and direct terminal connections validate the active remote credentials.
Remote access is a runtime toggle, not a new startup mode. The happy path is intentionally short so it works for quick mobile access without VPN setup.
Run AO normally. Dashboard starts local and local access stays easy.
The dashboard calls /api/remote-info to enable remote access.
cloudflared is downloaded if needed and starts a quick tunnel.
The modal shows public URL, QR code, username, and password.
Mobile browser opens the public URL and signs in with Basic Auth.
V1 is for a user-controlled development machine and a temporary public tunnel. It is not a hosted multi-user remote-control service.
Credentials are stored in the AO global config. This is a deliberate V1 tradeoff for a local developer tool, and should be surfaced plainly in the UI.
~/.agent-orchestrator/config.yaml
remoteAccess:
username: ao
password: example-password
Public tunnel traffic can reach Next through a loopback socket. V1 now avoids loopback bypass when proxy headers contain an external client address.
Shutdown is now guarded against repeated signal handling and exits cleanly after the server close callback.
web-dir.ts now uses shared platform helpers instead of direct
process.platform checks.
Real tradeoff: credentials are stored in local plaintext config. Acceptable for V1, but the UI should warn users that this is local config storage.
Basic Auth attempts are not rate limited. Generated passwords reduce practical V1 risk, but V2 should add throttling or lockout behavior.
AO_REMOTE_WS_TOKEN_SECRET lives in the process environment. That is
acceptable for an ephemeral local process.
atob in middleware
Next middleware can use atob. Server code uses Buffer
where Node APIs are available. Existing tests cover Basic Auth decoding.
| Capability | V1 | Hardened V2 |
|---|---|---|
| Login model | Basic Auth | Token login plus HttpOnly session cookie |
| Credential store | Plaintext local config | Hashed/tokenized credential store |
| Session lifetime | Browser-managed Basic Auth lifetime | Explicit token TTL and session TTL |
| Abuse controls | No rate limit | Rate limit, lockout, revoke sessions |
V1 is enough if the product goal is temporary mobile access for a local developer: click Remote, scan QR, authenticate, and control AO from mobile.
packages/web/src/middleware.ts
packages/web/src/middleware.test.ts
packages/web/server/direct-terminal-ws.ts
packages/web/server/remote-auth.ts
packages/web/src/lib/remote-access-manager.ts
packages/web/src/components/RemoteAccessQR.tsx
packages/cli/src/lib/web-dir.ts
docs/mobile-access-v1.md