A coding agent that proves the job is done instead of saying so.

One command, Node 20.11 or newer, no other dependencies. Create a key on the key dashboard — ROK stores only its SHA-256 hash, so a lost key is replaced rather than recovered — then run rok in the project you want it to work on. The first run asks for the key and keeps it; nothing is written until the key has been checked against ROK.

rok "make the failing test pass"
rok -p "explain this repo" --plan   # read-only: no writes, no commands
rok models                          # what your key can use
rok undo                            # revert the last turn
rok upgrade                         # update this install in place

On a machine with no terminal — a script, CI — set ROK_API_KEY instead (setx on Windows, then open a new shell). A piped run never blocks on a prompt it cannot show.

The gate needs something to judge. ROK Code detects a verification command from package.json, pyproject.toml or Cargo.toml; rok init writes it to .rok/config.json, or pass --verify "npm test".

First run is the whole setup

Run rok and it asks for your key once, checks it against ROK before writing anything, and keeps it in ~/.rok/config.json — your config, never the project's. rok login replaces a rotated key, and rok doctor tells you what is wrong when something is.

Nothing to install, if you would rather not

npx rok-code "explain this repo" runs the newest published build straight from the registry, so you can try it on a repo without touching a global install.

It updates itself

rok upgrade asks the registry what latest is and replaces the copy that is running — but only where that is unambiguous. A project dependency, an npx cache or a source checkout get the exact command to run instead of a surprise edit to somebody else's manifest. rok upgrade --check reports and installs nothing, for CI.

The box never leaves the screen

The input is a bordered box docked at the bottom of the terminal and repainted in place: agent output, tool activity and reports are written above it, the command palette opens above it and filters as you type, long input wraps instead of scrolling sideways, and a status line underneath shows the model, the workspace, whether completion is gated and how many requests are queued.

Type ahead while it works

The box stays editable during a turn: write your next request and press Enter to queue it, Esc to interrupt the running turn and keep what you typed, Ctrl+C twice to leave.

A scoreboard, not a vibe

rok bench record freezes a real request into a case, rok bench replays it in a sandbox and scores it with your verification command, and rok bench compare does the same to a rival CLI — printing what each tool claimed beside what your command found.

Claude Code and Codex CLI are good tools, and both can be wired up to run your tests. The difference is what the harness does by default, and whether “done” is a claim or a measurement. Everything below is their own documentation, checked in October 2026 — read it there, because both move fast.

Whoever you pick, the useful habit is the same: give the agent a check it has to pass, and keep the receipt. ROK Code simply refuses to let the receipt be optional — and if you want the comparison to be about your code instead of a marketing page, rok bench compare will run both tools on your repo and score them with your own command.

Every agentic tool runs the same loop: send messages, call tools, repeat. What decides whether a long run ends in working code is whether “done” means anything. ROK Code does not take the model's word for it — finish is a tool call, and the harness runs your command before accepting it.

The harder question is whose failure it is reading. A harness that blames your change for a pre-existing red suite traps the model on somebody else's bug; one that waves failures through is not worth having. So before the first edit it records the identity of every failure your command already reports, and when the gate fails it runs the command once more — anything that disappeared was never yours. What is left is new (the model goes back to work, told exactly which failures are new), pre-existing (reported with the baseline as evidence, never chased, and after two refusals the harness stops refusing rather than burn the run) or flaky (the retry wins). /verify shows the verdicts and the history. Attribution never changes the exit code.

Four extension points, all file-based, so a project's rules travel with the repo and need no plugin API:

permissions

Tool(specifier) rules in .rok/config.json — a prefix rule like Bash(npm run test:*) stops at a word boundary, a glob like Edit(src/**) covers a tree, and deny beats ask beats allow. You can also write new ones straight from the prompt with /permissions allow.

hooks

Shell commands at PreToolUse, PostToolUse, UserPromptSubmit and Stop. A hook can block a call (exit 2), inject context, or just have a side effect — so “you may not finish until the changelog is updated” is a nine-line script instead of a hope.

commands

Any .rok/commands/*.md file becomes a slash command in the palette, with $ARGUMENTS substitution, a per-command model, and allowed-tools that narrows the tool surface — a review command literally cannot edit anything. They work headlessly too: rok -p "/review main".

MCP

stdio and streamable-HTTP servers from .mcp.json; each tool joins the agent as mcp__server__tool with the server's own schema, obeys permission rules, and is approved before it runs — a server that will not start is a status row, not a broken session.

The CLI also carries durable project memory (.rok/memory.md), a ranked symbol-annotated map of the codebase in every prompt, output that spills to .rok/artifacts/ instead of being truncated, and a vision model behind look_at_image — so the agent can check the UI it just built against the design it was given.