· About Cokpit
Cokpit: a workbench for coding-agent sessions
Cokpit is the development environment Kavish built to run Claude Code and Codex all day: terminals that outlive the window, a live view of what each agent changed, a control plane one agent can drive, and a hub that keeps sessions alive on a home server. This is what it is, the decisions that shaped it, and what the live drives taught.
What it is
Cokpit is a desktop workbench for people who work with AI coding agents from the terminal. It orchestrates the user’s own agent command-line tools, Claude Code and Codex today, as managed terminal panes, and surrounds them with a file explorer, a Monaco editor and a live diff of what each agent changed. The terminal is the control plane; the workbench is for reviewing and editing what the agents did.
Kavish built it because he was running several long agent sessions at once across a workstation and a home server, with no shared view and no way to keep a session alive when a window closed. He has used it daily since the summer of 2026; version 0.0.38 installed in October 2026, with a public site at cokpit.dev and a private alpha.
The decision that shaped everything
Cokpit embeds no provider SDK and stores no credentials. Each agent CLI signs in with its own login, for the user’s own use, exactly as its vendor intends; Cokpit only spawns it in a pseudo-terminal and streams bytes. An earlier version embedded an agent SDK and an in-app chat and handled provider credentials. That whole layer was removed. The result is the same category as a terminal or an editor: nothing proprietary inside, so the product can be distributed freely, and “multiple agents” means multiple panes rather than an embedded orchestration framework.
The second decision follows from the first. Agent edits appear in the editor and the explorer in real time with no approval step, because a file watcher refreshes the view whenever any process writes to disk. A review-before-apply mode with inline accept and reject is deferred by design; the hands-off flow is the product.
Three tiers
The app is a Tauri application with three process tiers. The webview is pure UI, sandboxed and locked by a content security policy: terminals, file tree, editor, layout and command palette, talking to the backend only over IPC. The Rust core owns process and filesystem lifecycle: the pseudo-terminal manager, the agent-CLI supervisor, the file watcher, workspace state and git diffs. The third tier is the agents themselves, the user’s own CLI processes, supervised by the core but never fed a credential.
Sessions that outlive the app
Pseudo-terminals do not run inside the app process. A separate daemon owns them, with a loopback framed protocol, a discovery file and a reconnect ring, so quitting the app keeps every session and relaunching reattaches. The app keeps only policy, which shell to launch and with what environment, and acts as the daemon’s client.
Two lessons came out of this on Windows. First, a running sidecar locks its executable, and an agent that keeps its tool server open for the whole session holds that lock across the app’s own restart; the first real over-the-air update failed on exactly this. Every sidecar now runs from a staged, version-named copy outside the install directory. Second, the control plane must never queue behind pane output. A live drive once saw a list command take ten seconds and a close command thirty-five, in exact multiples of a reply timeout, because one busy pane held a lock across a socket write that blocked under backpressure. Attachment state became a lock-free flag, every control request is answered even when it cannot be parsed, and a timed-out reply is never handed to the next request.
A control plane one agent can drive
An internal MCP server lets an agent running inside one pane orchestrate the rest of the fleet: list panes, spawn one with a named agent, send text, read recent output, signal or close, and record facts and lessons for later sessions. Each tool is a thin wrapper over a token-gated verb on a loopback socket, and the server discovers the running app the same way the command-line tool does, so a fresh Claude Code pane gets the tools with no setup.
The design rule that mattered most: fleet verbs answer with observations, never intentions. An early spawn acknowledged before the agent was ready, and the prompt was typed into a pane that ate it; an early close reported success having killed nothing, sixteen times in one drive. Spawn now waits for the pane to appear and for the agent to settle at its prompt, and close reports what it actually found. The server also refuses to let an agent target its own pane, and refuses any pane the list does not know, because the underlying write is fire-and-forget.
The canvas, browser panes and an agent’s browser
The canvas is an infinite pan-and-zoom surface showing every session at once. It is not a second app: it is a second view of the same pane instances the grid layout holds, so flipping between them keeps every terminal’s state, which took a registry of long-lived host elements and a strict same-commit handover rule.
Browser panes put a real browser engine beside the terminals, on a profile of their own so logins and extensions never touch the app’s. An agent gets its own browser too: an MCP server drives a separate set of panes over the debugging protocol, with element references that are unique per snapshot so a stale reference can never click the wrong thing, and a human can see every pane and take over at any time.
Voice
A fleet bar takes a spoken or typed instruction and hands it to a hidden conductor session that carries it out across the panes and reports back. Speech recognition and voice activity detection run locally and in-process; speech out is chunked on sentence boundaries so the first sentence plays while the rest renders. A cloud variant routes the instruction through a realtime model in text mode with the same verbs. The bug worth remembering: the conductor once answered in its hidden terminal instead of reporting, because the tool description for the reply verb read like an alarm. Tool descriptions ride the system prompt and beat any instruction buried in a priming message.
The hub
Everything the workbench does locally it also does on a hub workspace: a daemon on a home server owns the sessions, and the app attaches over a private network with a jailed file API, a bounded exec verb, port forwarding in both directions and the same agent tools on the hub side. That daemon has its own write-up: How Cokpit’s hub keeps an agent session alive.
Shipping it
Releases are signed, served from a self-hosted licence and update server, and installed over the air; the app checks every four hours and downloads in the background. One rule governs the licence side: a cached activation is authoritative, so a revoked or offline machine degrades to updates-only and is never bricked.
By the numbers
426 commits by the 0.0.16 release at the end of August 2026; on the hub-mode merge in September, 1,527 Rust tests and 2,266 frontend tests on the merged tree. Every feature above was accepted on a live drive at Kavish’s keyboard before it merged. Implementation was drafted by AI coding agents from his specs and plans, under his review and tests.