* feat(cli): export HAPI_SESSION_ID into wrapped agent env Publish the hub session id into process.env at session bootstrap so every downstream agent spawn inherits it. HAPI runs one hub session per CLI process (the runner forks a fresh hapi child per session; local is 1:1) and every flavor's agent spawn derives its child env from process.env, so a single seam covers claude / codex / cursor / gemini / opencode / kimi / grok / pi - runner-spawned and local - plus future flavors, without touching each launcher. Agents can read HAPI_SESSION_ID to self-target their own hub session over REST or shell helpers without listing /api/sessions. Prefer the MCP display_image tool for inline media when available; HAPI_SESSION_ID is the deterministic fallback for non-MCP tooling. Closes #1119 Co-authored-by: Cursor <cursoragent@cursor.com> * feat(scripts): self-target hapi-display-image via HAPI_SESSION_ID Teach the in-tree shell helper to use $HAPI_SESSION_ID for path-only / self invocations: GET /api/sessions/:id directly instead of listing /api/sessions. Explicit session prefixes keep the previous list path. Gives #1119 a tangible now benefit - the tool that forced the wasteful list-and-reverse-lookup dance no longer needs it inside a wrapped session. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(cli): defer HAPI_SESSION_ID export until lazy Codex materializes The provisional lazy-session id was exported at bootstrap before the hub row existed, so path-only self-targeting (GET /api/sessions/:id) could 404 while materialization was still pending. Export on onMaterialized instead, and await materialize in buildHapiMcpBridge before starting the MCP server / spawning Codex so the agent inherits an id the hub can resolve (and so hapiMcpUrl is persisted, not only local pending state). Addresses Codex review Major on #1121. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Debian <heavygee@oos-linux.in.lockhouse> Co-authored-by: Cursor <cursoragent@cursor.com>
HAPI
Run official Claude Code / Codex / Cursor Agent / Grok Build / OpenCode sessions locally and control them remotely through a Web / PWA / Telegram Mini App.
Why HAPI? HAPI is a local-first alternative to Happy. See Why Not Happy? for the key differences.
Features
- Seamless Handoff - Work locally, switch to remote when needed, switch back anytime. No context loss, no session restart.
- Native First - HAPI wraps your AI agent instead of replacing it. Same terminal, same experience, same muscle memory.
- AFK Without Stopping - Step away from your desk? Approve AI requests from your phone with one tap.
- Your AI, Your Choice - Claude Code, Codex, Cursor Agent, Grok Build, OpenCode—different agents, one unified workflow.
- Terminal Anywhere - Run commands from your phone or browser, directly connected to the working machine.
- Voice Control - Talk to your AI agent hands-free using the built-in voice assistant.
- Workspace Browser - Opt-in via one or more
hapi runner start --workspace-root <path>flags: browse scoped file trees from the web and start sessions in allowed subdirectories.
Demo
https://github.com/user-attachments/assets/38230353-94c6-4dbe-9c29-b2a2cc457546
Getting Started
npx @twsxtd/hapi hub --relay # start hub with E2E encrypted relay
npx @twsxtd/hapi # run claude code
hapi server remains supported as an alias.
The terminal will display a URL and QR code. Scan the QR code with your phone or open the URL to access.
The relay uses WireGuard + TLS for end-to-end encryption. Your data is encrypted from your device to your machine.
For self-hosted options (Cloudflare Tunnel, Tailscale), see Installation
Docs
Build from source
bun install
bun run build:single-exe
Credits
HAPI means "哈皮" a Chinese transliteration of Happy. Great credit to the original project.