Yapitalism

Drive terminal coding agents by voice, and never let the answer claim more than it proved.

You are away from your desk. You speak; an agent in a terminal does the work; you get a spoken reply. That reply is the only thing you have — you cannot see the screen. So the worst failure is not a crash, it is the voice saying "done" while your text sits unread in a prompt box.

Yapitalism is a local MCP server that lets a voice client reach your coding agents, plus a receipt layer that decides what the voice is allowed to say. If you are at your desk, use your screen — this exists for the hours you are not.

Public pre-alpha. Local-only. No production deployment, no external messaging, and no automation of closed-source clients.

How it fits together

MCP client (Codex · Hermes · Claude Code · Claude Desktop · Cursor)
    │  MCP over loopback — no public endpoint, no OAuth, no relay
    ▼
yapitalism MCP server          panes_list · pane_read · pane_send
    │                          pane_await · pane_task
    │                          panes_name · panes_unname
    │                          panes_create · panes_resume · pane_clear
    ├── superset backend       local host-service over tRPC (127.0.0.1:48900)
    └── tmux backend           capture-pane / send-keys

The agents it addresses: codex, claude, kimi, opencode — recognised by measurement (a process tree on tmux, the host's own agent registry on Superset), never by a caller's claim. A pane running anything else is refused, because typing into a shell and pressing Enter is running a command.

The voice client never reaches your machine directly: it drives a local agent session, and that session talks to this server over 127.0.0.1. Nothing is exposed to the network.

The part that matters: receipts

pane_send returns a verdict, not a shrug.

YELLOW is the whole point. Text left unsubmitted in an agent's input box looks identical to work in progress from outside — same spinner, same scrolling output, same HTTP 200. A voice that rounds that up to "done" costs you hours before you notice.

Explicitly not acceptance: an HTTP 2xx, a PTY write returning, terminal output changing, a revision advancing, or the prompt echoing your own words back.

Waiting is not the same as failing

A fixed deadline reports on the clock, not on the agent. An agent that thinks for a minute and then answers correctly was verified all along, and calling that YELLOW teaches an operator to ignore YELLOW. So the wait is an idle timeout: it restarts whenever the pane changes, bounded by a hard ceiling.

Pane movement decides only whether to keep waiting. It is never evidence of acceptance — that stays the canary alone. A YELLOW therefore says which kind it is:

• canary_timeout_pane_moving — the pane's text was still changing. Named after what was measured: a spinner, a clock, a log tail or a second agent sharing the pane all produce this without the intended agent doing anything. It is a hint that looking again may be worth it, never a claim that the agent is working.
• canary_timeout_pane_still — nothing moved at all.

What remains irreducible: if an agent silently ignores the text and prints nothing, no mechanism here can distinguish that from an agent that never received it. Verification needs the agent to emit something.

The second receipt: how the turn ended

Delivery is table stakes; the expensive failure is an agent that has been sitting on a yes/no question for forty minutes while you thought it was working. pane_await watches a pane until the agent's turn ends and says how; pane_task is send-then-await in one call — instruct, walk away, come back to one of:

An ended verdict re-verifies the agent process is still alive before it is claimed: the frozen prompt of a dead pane must not be celebrated as a finished turn.

Who may write, by transport

The bearer token answers who is calling; it never answered what they may do. Since 0.5.0: stdio clients write, always — the OS made that trust decision when it let the client spawn the process. Writes over HTTP are off by default and every refusal names the fix: yapitalism authority allow-http-writes, once, on that machine (yapitalism setup asks the same question while printing the HTTP registration lines). Reading, watching and doctor work on every transport regardless, and yapitalism-mcp --read-only turns writes off everywhere — install the watcher first, allow writes when it has earned them. Every write result carries its origin.

On tmux, the send path also pins the identity of the admitted agent (pid + start time) and re-verifies it immediately before Enter. An agent that exits into a shell between typing and submit gets the text staged but never submitted — typing is recoverable, Enter into a shell is command execution.

Where the checks happen

Most of the time this does not change what you do, and it is not read out loud. It is in the payload and in yapitalism setup, for when something goes wrong and you want to know what was actually checked before the write.

{ "status": "GREEN",
  "client_guarantees": ["idempotent_dispatch", "empty_prompt_check"],
  "missing_guarantees": ["optimistic_revision"] }

yapitalism setup prints the table for your machine. Today both backends land in client for most of it: the checks happen here, a moment before the write, rather than inside the host atomically with it. tmux cannot do the revision check at all.

No shipped Superset enforces these itself, and this tool used to claim it did. It concluded "guarded" from the fact that a procedure named terminal.send was routed. The terminal.send Superset actually ships takes {terminalId, workspaceId, text, submit} and guards nothing. The levels are now read from what the host's own validator requires — the difference between a name and a contract.

Both backends reach GREEN, and GREEN means the same thing either way: the agent emitted the one-time marker, so it received the text and processed it. The table is for diagnosing a machine, not something to reason about on every send.

Reviewing this repo

Whether you are a person or someone's agent asked "should I install this," the claims worth checking and where each one lives — verify, do not take our word:

• Authority and its boundaries, including the shared-machine exposure and the fail-closed bearer gate: SECURITY.md.
• What a caller can never do (closed launcher tables, non-agent refusal, occupied-prompt refusal, per-pane serialisation): src/yapitalism/mcp/tmux.py and src/yapitalism/mcp/backends/, each guard with a test named after the failure it prevents.
• What GREEN claims and does not claim: the receipts section above, and tests/test_canary.py for why an echo cannot satisfy it.
• This project's own past overclaims, retracted by name: CHANGELOG.md, 0.2.0 through 0.2.4.

Machines are panes too

A peer is another machine's yapitalism server, mounted under its own namespace: the codex pane tmux:%0 on the machine studio is studio:tmux:%0 here, in the same panes_list, addressable by the same pane_send. Receipts pass through verbatim — the peer proved them next to its own terminals, and this side only gives the ids their machine name back.

# on the peer (reachable over your tailnet):
YAPITALISM_MCP_HOST=100.x.y.z yapitalism-mcp   # tailnet bind requires the bearer gate

# on this machine:
yapitalism peers add studio http://100.x.y.z:8792/mcp --token-file <peer's token>

peers add verifies the peer answers as a yapitalism server before writing anything. A peer on a public address is refused unless allow_public is said explicitly; the tailnet is the transport, not the trust story — the peer's bearer token still decides who may call. Configured peers show up in yapitalism doctor with live pane counts.

Agents can be started and resumed on a peer too: panes_create and panes_resume take a machine argument naming one. The peer runs its own full gate chain — and starting an agent remotely is more authority than typing into one, so it has its own switch, off by default: yapitalism authority allow-remote-create, once, on the peer. To keep a peer's server alive across reboots, yapitalism service --host <its tailnet IP> prints a filled launchd plist or systemd unit; installing it stays your decision.

Say names, not ids