mirror of
https://github.com/wu736139669/hapi.git
synced 2026-08-05 06:24:37 +00:00
73fa846df3
* fix(web): drop "No response requested." assistant messages When Claude Code injects system messages (task notifications, system reminders) as user turns, Claude responds with "No response requested." In the HAPI web UI this appears as a reply to the user's message, making it look like Claude is ignoring their input. Filter these out in isSkippableAgentContent() (catches the fallback path in normalize.ts) and in normalizeAssistantOutput() (catches the primary path). Both checks verify the assistant message contains only the text "No response requested." with no tool calls. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(web): filter text block instead of dropping entire message Address bot review: dropping the whole normalized record breaks sidechain UUID threading (parentUUID chain orphans). Instead of returning null, suppress only the "No response requested." text block during content extraction. The message record (uuid, parentUUID, usage) is preserved so the tracer's sidechain grouping continues to work. Also remove the isSkippableAgentContent check since we no longer need to drop the message at that layer. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(web): move "No response requested." filter to reducer layer Address bot review: filtering in normalizeAssistantOutput() produced empty content arrays, breaking traceMessages() which reads uuid and parentUUID from content[0]. Sidechain child messages whose parentUUID pointed to the filtered message became orphaned. Fix: revert the normalizer to always emit the text block (preserving the UUID chain for the tracer), and filter the sentinel text in reducerTimeline.ts where text blocks become visible AgentTextBlocks. At this point tracing is already complete. Also adds reducer-level tests for the filter and updates the normalize test to verify the text block is preserved. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(web): scope sentinel filter to single-block assistant messages only Address bot review: the previous filter suppressed any text block matching "No response requested.", which could hide legitimate replies. Now the filter only triggers when the message has exactly one content block (msg.content.length === 1) — i.e., the assistant response is purely the sentinel text with no tool calls or reasoning blocks. This prevents false positives while still catching the system-injection auto-reply case. Add test for the multi-block case (text + tool call) to verify the sentinel text is preserved when other content exists. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(web): add parentUUID structural check to sentinel filter Address bot review: raw text match alone could theoretically suppress a legitimate reply. Add c.parentUUID !== null as a structural guard: - Sentinel auto-replies always follow a prior assistant turn, so their parentUUID is set (pointing to the previous message in the chain). - A first message in a conversation has parentUUID: null and will never be filtered. Combined conditions: msg.content.length === 1 (sole block, no tool calls) AND c.parentUUID !== null (not the first reply) AND exact text match. Add tests for the parentUUID=null escape hatch. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(web): use injected-turn UUID tracking for sentinel filter Address review: use structural markers instead of broad text matching. 1. Pre-scan collects UUIDs from sidechain content blocks (system- injected user turns). The sentinel filter now only triggers when parentUUID points to one of these known injected turns. 2. Move task-notification event extraction from normalizer to reducer. Previously, task-notifications with summary were normalized as role:'event', losing their uuid. Now they stay as sidechain (uuid preserved for pre-scan), and the reducer extracts the summary as an agent-event block. 3. Remove redundant 'uuid' in c guard (always present on sidechain type). False positive analysis: a legitimate reply is only suppressed when ALL of: (a) sole content block, (b) parentUUID matches a sidechain-injected turn, (c) exact sentinel text. This combination cannot occur for real user-facing content. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(web): add parentUUID to sidechain content type for tracer linkage The sidechain content block was missing parentUUID, so traceMessages() could not chain system-injected user turns (task notifications, system reminders) inside a Task sidechain back to their parent. This caused later sidechain messages pointing to the injected turn's UUID to become orphaned and disappear from the Task card. Add parentUUID to the sidechain type definition and propagate it from normalizeUserOutput() in both the isSidechain and non-sidechain paths. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(web): handle array-content sidechain user messages to prevent prompt leak Sidechain user messages can arrive with either string content or array content ([{type:'text', text:'...'}]) depending on how Claude Code serialises them. The previous fix only handled the string case, causing intermittent prompt leaks when array format was used. Now normalizeUserOutput extracts text from array-content sidechain messages and emits them as sidechain blocks, so the tracer can match them to their parent Task tool call. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * test(web): verify parentUUID propagation from assistant output data Add integration tests confirming normalizeAssistantOutput correctly maps data.parentUuid to text block parentUUID (used by the reducer's sentinel detection). Tests cover both present and absent parentUuid. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> --------- Co-authored-by: HAPI <noreply@hapi.run>
HAPI
Run official Claude Code / Codex / Gemini / 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, Gemini, OpenCode—different models, 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.
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.