← §A Overview · §B Product · §C Architecture · §D Rationale
This page explains the reasoning. The auditable record — the call, its status, supersessions — lives in the Decisions ledger, which is the single source of truth for status. Each choice below links down to its entry.
claude -p over tmux / screen-scrapingWe drive Claude headlessly with claude -p --output-format stream-json --resume. It's the same engine as the interactive TUI, but it emits a structured event stream we can map cleanly to a status chip and edit cards. The alternative — driving an interactive session over tmux and scraping the terminal (how amux does it) — pays for long-lived fleets with fragile ANSI parsing we don't need for a single document. We verified claude -p still draws from the Claude subscription. ledger → · amux →
You, Claude Code, and Codex read and write the same file; the page reflects disk, never ahead of it. Provider sessions and browser transcripts remain separate convenience context; the repository and shared brain carry durable truth. disk ledger → · provider ledger →
The explicitly selected provider edits the file with its own tools; the server hashes before and after, owns one global lifecycle and snapshots, and reloads from disk. It never assembles HTML from model stdout. Both first-party adapters emit normalized provider-tagged frames with no silent fallback or hidden context handoff. ledger →
Node ≥18 built-ins, ESM, and zero runtime dependencies keep the local bridge small. The server binds to loopback, injects a per-process token, validates same-origin mutation requests, and applies one shared repository path policy. Claude receives file tools; controlled Codex disables network and optional integrations but retains directory-level write ability and saved auth access. ledger →