chit

Studio

A local visual control tower for live Chit activity across your sessions

Studio opens as a control tower: a calm view of what is alive across Chit right now. Foreground loops running in your sessions and durable background jobs show up side by side, with the selected run's detail and a small console of recent transitions. It reads the runtime, and it can stop a background run. It does not launch, apply, or clean up work.

Studio does not need a chit in the directory. It is a window onto activity, not a manifest editor, so it opens the same way from any directory, including an empty one. When nothing is running, it says so.

Studio is live-only for now. Completed-run receipts and full audit transcripts remain in MCP and CLI through chit_trace, chit_audit_show, and chit audit; a future Studio receipt view should reuse those same refs instead of reviving the old editor drawers.

Launch

chit studio

chit studio boots a local server in the invocation cwd, generates a launch token, serves a React app, and opens the browser to it. The server is Hono on Bun, bound to 127.0.0.1, and its lifetime is tied to the CLI process. The tower is the first screen for every launch.

The local server is part of the threat model. A launch token is generated at boot, never appears in the URL, and is required on every /api/* request. The server also enforces a Host allowlist (127.0.0.1, localhost, [::1]). When the server restarts, old tabs get a 401 and must refresh to reconnect.

The four parts

  • Top bar. The chit live identity and a count of how many runs are live right now.
  • Session rail. A compact summary of active sessions, split into two groups. Foreground holds in-flight loop iterations mirrored from the cross-process registry. Background holds durable jobs from the job store, with stale derived when a worker has gone silent. The rail is a summary, not a dense table: one row per run with its phase, age, scope, and a short status line. The whole row selects.
  • Run detail. The selected run, shown as its execution wiring: when a background run was launched from a recipe and bound to a manifest, the approved recipe and bound manifest appear as blocks connected into the agent blocks (which agent ran, via which adapter), so the chain reads recipe to manifest to the implementer, reviewer, and checks. Runs without that identity show just the agent blocks. Alongside are the derived ages and a chit-managed worktree path when one is present.
  • Console. A small event stream of local transitions, newest first. A run appearing, changing phase, or disappearing logs one line; steady-state age ticks do not. The console holds the recent tail so the final transition stays readable after a run clears, and a page reload starts a fresh read session.

What it reads

Studio polls GET /api/live while the page is open, lightly and on a self-scheduled timer. That snapshot is the only thing the browser sees. The data is produced by the host (the CLI), which owns the Chit state readers; a standalone Studio with no host shows an empty tower rather than an error.

Every row is a glance summary, safe to hand a browser: run ids, a bounded scope and task one-liner, phase or lifecycle display, ages derived against the reader's clock, agent and adapter participants with model and reasoning effort when known, recipe identity, manifest path and digest when bound, a compact status line, and a safe worktree path only when one is already present. A row never carries prompts, model output, review prose, environment keys or values, permissions, manifest contents, audit blobs, or raw participant config. Studio does not read private state files in the browser, and it does not stream model output.

Run actions

Studio can request cancellation for a durable background run. The request goes through the same intent-first background cancel path as chit_cancel: Chit records the cancel intent, then signals the worker. The run settles through the normal job machinery and keeps its receipts.

Foreground loops do not show a cancel action in Studio. They are owned by the MCP session that is currently supervising them, so stop them from that session with chit_cancel or the client's own interruption behavior.

Not supported yet

Launching runs, applying changes, cleaning up worktrees, plan actions, and live model-output streaming are not wired up.

On this page