HAPI Remote Agent Console

The privacy policy is unusually detailed about data flows (hub, push relay, FCM/APNs, transcription and model providers), which is a genuine strength for data-flow transparency. Least privilege is weak: without --workspace-root the runner can browse and spawn sessions anywhere the OS account can reach, and it exposes a remote terminal PTY, so the permission surface is large and only optionally narrowed — scored 1. User confirmation exists via remote permission approve/deny from phone, but no enforced confirmation for destructive or externally effectful actions — 2. Sensitive data handling: 256-bit token, HTTPS enforced on Android, platform-protected credential storage, and test env whitelisting that blocks secret leakage are good; however the push relay keeps correlatable token hashes and source IPs, and private FCM builds send unencrypted payloads — 2. Dependency security: only package.json and a pinned Bun version are visible; no dependency audit, lockfile review, or vulnerability remediation evidence — 1. External effects: remote terminal, session spawning, attachment upload and push all produce real external effects; documented but without a unified confirmation/audit mechanism — 1. Rollback: runner stop, session stop, version handoff and doctor clean exist, but no session/data-level rollback or undo — 1. Source attribution: README credits Happy and states HAPI derives from it, LICENSE is AGPL-3.0, attribution is clear; publisher identity is unverified, so 2.

Self-consistency: README, installation and FAQ agree on commands (hapi hub, hapi server alias, runner, doctor), ports and config — 2. Dependency availability: requires Bun 1.4.0, external agent CLIs, tunwg download, npm platform packages and a Homebrew tap; any missing piece breaks install, and docs admit mirrors may lag — 1. Failure messages: FAQ and hapi doctor cover connection refused, invalid token, runner startup and missing agent with concrete steps, and test code insists scan failures must throw rather than silently pass — 2.

Audience and scenarios: targets many agents (Claude Code, Codex, Cursor, Grok, OpenCode, Kimi, etc.) and many clients (iOS/Android/Web/PWA/Telegram) across local, remote and AFK-approval scenarios — 3. Capability boundaries: docs note remote mode does not move execution, laptop sleep interrupts sessions, Windows needs Bun 1.3.14+, but some features (shared Codex sessions, voice) are described thinly — 2. Trigger precision: it is a CLI/service rather than a prompt-driven agent, with no explicit trigger conditions or scope definition — 1. Environment fit: covers macOS/Linux/Windows, self-hosting and relay, Tailscale/Cloudflare, but with platform caveats — 2.

Information architecture: README plus a well-separated docs/guide set (installation, FAQ, privacy, native apps, deployment) — 3. Install notes: npm, npx, Homebrew, prebuilt binary, source build, plus hub/runner configuration — 3. Naming stability: hapi server and hapi hub aliases coexist and the package name @twsxtd/hapi differs from the repo name, showing naming legacy — 2. Examples and FAQ: extensive FAQ with comparison tables and troubleshooting — 3. Known limitations: sleep, LAN binding and Windows PTY caveats appear in FAQ but there is no consolidated limitations list — 2. License: full AGPL-3.0 text in LICENSE and AGPL-3.0-only stated in FAQ — 3. Versioning/changelog: only release workflows and version inputs; no CHANGELOG — 1. Maintenance responsibility: SECURITY.md is a single line pointing to advisories, with no maintainers, support scope or SLA, and publisher identity is unverified — 1.

Output usability: terminal, web, native apps and approval flows are practical, but this static review did not verify runtime behavior — 2. Marginal value: adds remote control, session persistence and multi-machine support over using agent CLIs directly, though at deployment cost — 2. Cost-benefit: requires self-hosted hub, runner, HTTPS/relay, multi-platform builds and coordinated upgrades across machines, a high operational burden — 1.

Claim traceability: most claims in the privacy policy and installation docs map to repository files and config keys — 2. Cross-source corroboration: README, FAQ, installation and privacy docs corroborate commands, ports and push modes — 2. Fact/inference separation: docs distinguish self-hosted data from external services and the privacy policy labels metadata versus encrypted content, but there is no independent validation of security claims — 2.