Revamp communication layer: daemon with stream-json instead of PTY/tmux

[kwannoel]

Summary

Replace the current PTY + tmux + xterm.js communication layer with a separate Rust daemon that spawns Claude Code (and Codex) using --output-format stream-json --input-format stream-json. The Tauri app talks to the daemon over a Unix domain socket using a JSON-lines protocol.

Design doc: docs/plans/2026-04-13-daemon-revamp-design.md (branch: daemon-revamp-design).

Reference implementation: slock-daemon — annotated source showing how a daemon can drive Claude Code with structured I/O, inbox queuing, and an agent state machine.

Motivation

Three limitations of the current architecture compound:

1. No structured data. Output is ANSI bytes. The UI can't reason about thinking blocks, tool calls, or message boundaries.
2. Fragile process control. Message delivery is typing into a PTY. No inbox, no mid-work notifications, no first-class busy/idle state beyond hook signals.
3. tmux-coupled lifecycle. Session persistence, reattach artifacts, and hook-based status signals are all tangled into one layer.

Key decisions

• Separate daemon process, written in Rust, in a new Cargo workspace alongside src-tauri.
• JSON-lines over Unix domain socket for UI ↔ daemon IPC.
• Incremental replace: gate behind a per-session communication_mode flag. Terminal/tmux path stays until the daemon path proves out.

Proposed rollout

• Phase 1 — Workspace refactor, daemon skeleton, DaemonClient in Tauri. No UI change.
• Phase 2 — Per-session flag + StructuredTerminal.svelte. Both modes coexist.
• Phase 3 — Default new sessions to daemon mode. Migrate auto-worker, staging, secure-env, summary pane.
• Phase 4 — Retire pty_manager, tmux, Terminal.svelte, hook-based status detection.

Open questions captured in the design

• Daemon lifecycle: Tauri sidecar on launch (leaning here), launchd, or lazy spawn?
• Daemon upgrade path when the Tauri app updates.
• stream-json format stability — need a compatibility layer + tests.
• Raw key input (CSI-u modifier sequences) has no direct analogue in structured mode; features relying on it need redesign.
• Staging under the daemon model: likely a second UI subscriber, needs phase 2 design.

Scope note

This issue tracks the overall effort. Each phase will get its own implementation plan and likely its own PR(s). Too large for single-shot auto-worker execution.

[Snailflyer]

The stream-json daemon path should make semantic UI much easier, especially for tool calls and busy/idle state. One boundary I would keep explicit during the migration: replacing PTY/tmux for interaction does not remove the need for live-session receipts.

For mobile/remote control, the daemon should still return something like: session id, active turn/run id, input accepted/rejected, host process applied/stale/timeout, interrupt accepted, and handoff target. Otherwise the UI can become more structured but still leave the user guessing whether a phone-side action actually reached the running process.

Faryo takes the opposite, narrower route by keeping tmux as the source of truth and putting a lightweight phone/browser workbench above it. Different architecture, same acceptance shape: a mobile action only counts if it lands back in the same live session. Public walkthrough: https://github.com/Snailflyer/faryo/releases/tag/v1.0.7