You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Port the review/question/direction UI from a browser-rendered SPA (currently inlined into the haiku MCP binary as `HAIKU_UI_HTML` and served via the local MCP HTTP server) to a native desktop application. The agent stops opening a browser tab — instead it pings the desktop app, which raises a focused window with the same review experience.
This is a meaningful migration with real scope; filing it as a feature request to anchor the discussion before any work starts.
Why
Today's flow opens a browser tab for every review/question/direction surface. That's:
Auth-sensitive (the URL fragment carries a session token; users have flagged "not loving a token in URL")
Stuck inside web platform constraints (no native notifications, no system tray, no offline-first behavior, no good window-grouping per intent)
Tied to the user's default browser, which may have privacy extensions / theme overrides / etc. that interfere with the rendered review surface
A native desktop app fixes all of that. Token lives in OS keychain, not URL fragments. Review windows can be grouped per intent. System tray icon shows active intents. Native notifications surface review-ready signals without focus-stealing.
Proposed shape
1. Tech-stack tradeoff (the real decision)
The issue title says "React Native" but the right answer probably isn't React Native. Three realistic options:
Stack
Pro
Con
Tauri (Rust shell + WebView)
Reuses the existing `packages/haiku-ui` React 19 SPA almost verbatim; tiny binary; no Chromium ship-along; cross-platform.
Rust toolchain in CI; per-OS WebView quirks (WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux).
Electron
Reuses SPA verbatim; widest ecosystem; auto-updater is solved.
~150MB binary per platform; ships Chromium; battery + memory cost.
React Native (with react-native-web bridge)
Single codebase if we want to add iOS/Android later.
Requires rewriting the entire UI — react-native components don't share with react-dom; massive engineering cost; questionable value (the UI is desk-bound by nature).
Recommendation: Tauri. It lets us reuse the existing `packages/haiku-ui` SPA almost as-is, ships small binaries, and is the modern default for "wrap a web UI as a desktop app." React Native is the wrong tool for this — it's optimized for mobile, and rewriting a complex review tree (annotations, inline comments, virtual scroll, pin canvas, screenshot annotation) in react-native primitives would burn months for no user-facing benefit. If we ever want a phone client, that's a separate project that probably does NOT share code with the desktop app.
2. What stays (most of the codebase)
`packages/haiku-ui` — the React SPA. Kept verbatim; Tauri loads it as the WebView root.
`packages/haiku-api` — wire schemas. Unchanged.
The HTTP server in `packages/haiku/src/http/` — unchanged. Tauri talks to it the same way the browser does today.
Annotation, screenshot, inline-comment, feedback flows — all unchanged at the React level.
3. What changes
New package: `packages/haiku-desktop` — Tauri shell. Per-platform builds (macOS, Windows, Linux). `tauri.conf.json` sets the WebView entrypoint to load the bundled `HAIKU_UI_HTML`.
Tauri ↔ MCP server discovery — desktop app discovers the running haiku MCP server via a known file (`~/.claude/haiku/socket` or a standard port range), or starts a local server itself if none is running. Today the MCP server is launched by Claude Code; the desktop app needs to find it without a hardcoded port.
Token storage — instead of URL fragments, the desktop app holds session tokens in OS keychain (`tauri-plugin-stronghold` or platform-specific keychains).
Window-per-session model — instead of one tab per review URL, the desktop app raises a focused window per session; closing the window posts the decision back to MCP same as today's tab-close hook.
System tray — shows active intents + count of pending reviews; click → focuses the relevant window.
Native notifications — when a review is requested, fire a native notification ("Stage 'design' awaiting review for intent "); click → focuses that intent's window.
The browser-served SPA stays working. The desktop app is opt-in: if it's installed and running, the MCP server detects it (via local socket / IPC) and routes review requests there instead of opening a browser tab. If it's not running, the browser fallback is unchanged.
Phase 1: Tauri shell that loads the existing SPA verbatim, talks to the MCP HTTP server over localhost, opens a window per session. No native features yet — proof of concept.
Phase 2: Token migration to OS keychain; remove URL-fragment tokens for desktop-app users.
Phase 3: System tray + native notifications.
Phase 4: Auto-updater wired to plugin releases.
Phase 5: Discontinue browser-served SPA in MCP binary (saves ~700KB on every haiku install) once desktop install is the default. Keep an opt-in for users who explicitly want the browser flow.
Acceptance criteria (high-level — each phase gets its own sub-issue)
Phase 1 ships installable Tauri app on macOS/Windows/Linux that renders the existing review UI
MCP server detects running desktop app and routes review/question/direction sessions to it instead of opening a browser
Tokens move out of URL fragments into OS keychain
System tray shows active intents
Native notifications fire on review-ready
Auto-updater integrated with plugin release pipeline
Browser fallback documented as the opt-out path
Out of scope for this issue
iOS / Android clients (separate project; would NOT share code with the desktop app)
VS Code extension (different surface entirely)
Mobile-responsive web UI (the existing SPA is desk-bound; mobile would mean a different IA)
Cost estimate
Real engineering. Phase 1 alone is probably a few weeks of focused work — Tauri scaffolding, IPC discovery protocol, per-OS testing, signing certificates, distribution pipeline. Full migration through phase 5 is multi-month. Should be its own H·AI·K·U intent under a new `desktop-app` studio (or as a multi-stage project under the existing `software` studio).
Summary
Port the review/question/direction UI from a browser-rendered SPA (currently inlined into the haiku MCP binary as `HAIKU_UI_HTML` and served via the local MCP HTTP server) to a native desktop application. The agent stops opening a browser tab — instead it pings the desktop app, which raises a focused window with the same review experience.
This is a meaningful migration with real scope; filing it as a feature request to anchor the discussion before any work starts.
Why
Today's flow opens a browser tab for every review/question/direction surface. That's:
A native desktop app fixes all of that. Token lives in OS keychain, not URL fragments. Review windows can be grouped per intent. System tray icon shows active intents. Native notifications surface review-ready signals without focus-stealing.
Proposed shape
1. Tech-stack tradeoff (the real decision)
The issue title says "React Native" but the right answer probably isn't React Native. Three realistic options:
Recommendation: Tauri. It lets us reuse the existing `packages/haiku-ui` SPA almost as-is, ships small binaries, and is the modern default for "wrap a web UI as a desktop app." React Native is the wrong tool for this — it's optimized for mobile, and rewriting a complex review tree (annotations, inline comments, virtual scroll, pin canvas, screenshot annotation) in react-native primitives would burn months for no user-facing benefit. If we ever want a phone client, that's a separate project that probably does NOT share code with the desktop app.
2. What stays (most of the codebase)
3. What changes
4. Backwards compatibility
The browser-served SPA stays working. The desktop app is opt-in: if it's installed and running, the MCP server detects it (via local socket / IPC) and routes review requests there instead of opening a browser tab. If it's not running, the browser fallback is unchanged.
5. Distribution
Migration phases
Acceptance criteria (high-level — each phase gets its own sub-issue)
Out of scope for this issue
Cost estimate
Real engineering. Phase 1 alone is probably a few weeks of focused work — Tauri scaffolding, IPC discovery protocol, per-OS testing, signing certificates, distribution pipeline. Full migration through phase 5 is multi-month. Should be its own H·AI·K·U intent under a new `desktop-app` studio (or as a multi-stage project under the existing `software` studio).
Related