Oko CLI reference
Every public command, one exact contract.
These pages follow the current oko dispatcher. Group commands and every public leaf have a stable, canonical route with the accepted invocation, inputs, state effects, and refusals.
chat#
- oko chat — Dispatches the chat command group.
- oko chat autoconfigure — Materializes Oko’s local Slack configuration from defaults and the signed-in member's organization's Slack routing, read through oko.
- oko chat post — Posts a message through Oko’s exact Slack webhook or bot credential; oko sends it.
- oko chat status — Reports actual bot authentication, conversation access and optional Socket Mode readiness.
sessions#
- oko sessions — Dispatches the sessions command group.
- oko sessions list — Every terminal session Oko's broker holds, with whether its process still runs, the publication it backs and the command that attaches to it (`oko sessions attach 'ID' --socket 'BROKER'`); with --external, the agent processes running on this machine that the broker did not start.
- oko sessions agents — Every agent session on this machine a supervisor needs to read: each one a live process holds, and with --hours each one written in the last N hours — who holds it, whether it is working, and what it stands on.
- oko sessions role — Records which agent session supervises and which sessions execute under it, so the role is a fact Oko shows and acts on instead of a sentence in a brief.
- oko sessions resume — Hands a session a message by continuing it in a new terminal of Oko's broker with its own runtime (`omp --resume` for an OMP session) on the model named or chosen, and answers once the message is the newest prompt of a transcript — whether or not the broker started the session.
- oko sessions model — Moves a live session to another model between turns, losing no work: a harness takes its model when it starts, and text typed into a running one reaches the model as a prompt, not as a harness command.
- oko sessions policy — The model policy: a session a provider stopped on its limit is moved to another declared model with capacity, or continued on its own once the provider's wait is over, without anybody retyping it or moving it by hand.
- oko sessions supervision — The standing Stado pass settles stalled calls and stopped turns, then decides the executor count and model mix from observed subscription capacity, independent checkout work, measured repair throughput and overload. It retains both actions and refusals.
- oko sessions attention — Which live agent needs its supervisor now, ranked, each with the evidence for every sign it shows and the action that sign needs, so a supervisor acts on the agents that matter instead of reading every transcript tail.
- oko sessions messages — Everything one session's transcript says, whole and in order: each text it wrote, each tool call with its arguments, each tool result with its text and whether it is an error, each message it was sent and each stop refusal it received, untruncated. A supervisor reads an executor's answer here instead of selecting lines from its screen or transcript; an executor that may write no text answers through its tool calls, so they are printed too.
- oko sessions screen — Everything one session's terminal printed, as the broker keeps it.
- oko sessions start — Starts a new agent session, or any executable, in a new broker-owned terminal session.
- oko sessions send — Types a message into the broker terminal running a session, or leaves it in the inbox of a session a process outside the broker holds, for that process to take at its turn's end; every supervised executor receives the declared wording for its measured standing, then the exact requested instruction.
- oko sessions inbox — Shows the inbox of a session a process outside the broker holds: which process reads it, and every message left there by `oko sessions send`, with whether it still waits, was delivered or was refused.
- oko sessions interrupt — Stops the tool call a session's harness is running, or the model answer it waits on, so a command or answer that hangs no longer holds an executor still and the message its supervisor typed with `oko sessions send` is read next, and reports what a call left unfinished in the checkouts it worked in.
- oko sessions repaint — Asks the program in one session to redraw its screen.
- oko sessions end — Ends one session by its id, or every session a selector admits, instead of by a list somebody wrote down.
- oko sessions adopt — Resumes an external session of a harness the catalogue gives a resume command (Claude Code, Codex, Jeden, OMP) inside a broker session, its model traffic routed through Brama, once its own process has ended its turn.
- oko sessions attach — Joins this terminal to a session: locally at the attach socket the broker lists for it, or as a viewer of a session published through a WebSocket relay.
- oko sessions publish — Offers one session through a WebSocket relay as its publisher and lists it for the organization's members for exactly as long.
- oko sessions unpublish — Withdraws one of this member's shared-session publications; the session itself keeps running.
- oko sessions scorecard — What each agent session and each model delivered and what it cost, measured from the registers and transcripts: commits and repairs, consent dialogs, interruptions, stalled tools, current time waiting for a model, model turns without a tool or commit since progress, ignored directives, calls and tokens.
- oko sessions scorecard credits — Compare source-cited verified repair credits with compiler-charged commits for sessions and models, without crediting a claim that only says repaired.
- oko sessions orphans — Lists recorded process trees whose owning session ended, alongside unattributed adopted terminal processes and the reason they cannot be reaped.
- oko sessions reap — Signals a recorded ended session's remaining process tree, preserving the reason, requested identities and actual outcome.
- oko sessions waits — The wait watch: a tool call that waits on something that will not answer by itself is acted on by what it waits on, at once, and every such occurrence is counted on one class defect — no person watching a screen.
report#
- oko report — Inspect fleet delivery and usage by executor, model, provider, product and organization member. This is the report projection of sessions scorecard, not a separate metrics store.
scorecard#
- oko scorecard standing — Read the measured standing and declared supervisor wording for each executor and model, rather than choosing a tone from the message text.
goals#
- oko goals — Dispatches the goals command group.
- oko goals snapshot — The signed-in member's canonical goal document, read without changing it.
- oko goals truth — Prints the transcript-truth oracle’s completed/open goal view.
- oko goals reconcile — Applies the transcript-proven goal completions of one local day; the suggestions pass runs it for today after the member's forecast end of day.
- oko goals recompute — Recompute runs over the signed-in member's goal document. stage rebuilds a window (or classifies today's unclassified turns) through the goal-lifecycle model and materializes that window's prompt mappings from this machine's transcripts as part of the same run; list and show find and read runs; review records duplicate decisions in a new run; apply writes a reviewed run and rollback undoes it.
- oko goals evaluate — Scores the goal-lifecycle model on the labelled goal-intent cases.
- oko goals extract — Runs the local goal lifecycle model over Transcript Lake user turns.
- oko goals clean — Shows the sanitized user turns that goal extraction would consume.
- oko goals check — Diagnoses the goal pipeline: compares the goal snapshot with today's catalogued transcripts.
telemetry#
- oko telemetry — Prints recent working-hours telemetry from normalized transcript turns.
- oko telemetry forecast — Forecasts a day's working window, tomorrow unless --on names another, from matching historical weekdays.
- oko telemetry publish — Publishes the signed-in member's work telemetry to the shared snapshot their team plans from.
- oko telemetry team — Reads every published work telemetry snapshot of the member's organization.
- oko telemetry — Dispatches the telemetry command group.
- oko telemetry work — How a member worked, day by day, from the transcripts written in the window: Transcript Lake's Oko export, or the trees each --root names. Sessions Oko's own automations opened are left out of the working hours. With --by provider, each member's prompts counted by the harness that took them, under its display name in Oko's harness catalogue (the name `oko agent harnesses` and `oko stats` show), or its runtime id when the catalogue does not know it.
- oko telemetry tokens — What the member's tokens would cost, day by day, from the same transcripts, priced from the token price catalogue; with --by, which session, subscription account or model used them, and in which UTC hour or day, call by call from every harness's own transcript tree.
- oko telemetry inputs — Which inputs take the sessions' context and tokens. Each OMP call records the context it was sent with; the growth between two calls is shared among the entries appended between them by their characters, and each entry stays in the context, costing its tokens again on every later call, until the next compaction. So the inputs (the operator's messages, the model's answers, each tool's results, each hook's paragraph of a stop continuation, compactions, the system prompt) add up to the context the calls sent.
- oko telemetry forecast — When the member will start and stop tomorrow, or on the day --on names, from those weeks of days.
- oko telemetry publish — Writes the member's days and token rows as their row of the shared work telemetry snapshot their team plans from.
- oko telemetry team — Reads every member's row of the shared work telemetry snapshot, or one member's.
- oko telemetry calendar — The member calendar: each member's days keyed in that member's own timezone. --format html writes one self-contained page for every member, with the goals file beside them when named; --format svg writes one member's engaged calendar as a drawing, and --format png has the system Quick Look renderer rasterize it for the places a browser is not. --explain explains one day from the turns behind it.
pricing#
- oko pricing — Dispatches the pricing command group.
- oko pricing refresh — Refreshes Oko’s locally cached model-token price catalog from provider pages.
context#
- oko context — Dispatches the context command group.
- oko context snapshot — Reads the masked transcript catalogue from the shared Oko database and the named company/Slack caches through oko, without a Python bridge or model call.
- oko context advise — Generates a structured CEO/PM advisory from strategy and live GitHub execution data.
- oko context refresh — Refreshes Oko’s searchable local cache of the team’s chat workspace.
- oko context search — Searches the chat workspace, Oko’s local cache of it, or both and returns deduplicated results.
gateway#
- oko gateway check — Says whether this machine can reach Brama as oko: the route, the bearer, the signing identity and the gateway’s answer.
- oko gateway — Dispatches the gateway command group.
- oko gateway check — Says what this machine can say about reaching Brama without spending a completion: where the gateway is, whether Oko can read its bearer and its signing identity, what the gateway answers to that bearer on /v1/models, and what /readyz says about itself for Oko's agent — whether it serves, whether it is degraded and why, its build, its routes by provider, and every account it cannot redeem or route.
- oko gateway send — The one model call as Oko. With --prompt, one chat completion — the prompt as the only user message — asked of the OpenAI-compatible service `oko model-service set` declared, with its model, or of Brama on Oko's declared route; Tama's model-judged guards ask through it. Without --prompt, one request to the gateway with the body from standard input. Bearer and signature are attached either way.
- oko gateway object — One chat completion as Oko whose answer is bound to a JSON Schema, printed as the object it answered: how a program outside Oko has a model decide something without reading the first word of a line of prose.
suggestions#
- oko suggestions — Dispatches the suggestions command group.
- oko suggestions tick — Runs one permanent responder tick, including replies and opt-in proactive Slack work.
- oko suggestions reply — Runs only the targeted Slack reply portion of a suggestions tick, or answers one message outside Slack and posts it nowhere.
- oko suggestions costs — Refreshes the suggestions cost snapshot without scanning or posting to Slack.
hooks#
- oko hooks — Dispatches the hooks command group.
- oko hooks install — Materializes Oko’s supported hook bundle into local Claude/Codex hook settings.
- oko hooks publish — Publishes Oko’s owned hook bundle for a team.
- oko hooks pull — Fetches the team hook bundle and materializes it locally.
autonomy#
- oko autonomy — Dispatches the autonomy command group.
- oko autonomy mode — Chooses what Oko may do on its own on this host, under the limits the operator states. It is the one verb for the choice: enable, disable and their --mode spelling are gone.
- oko autonomy policy — Reads the stored autonomy policy (VERB show), or replaces it whole with the policy document on standard input (VERB set).
- oko autonomy state — Reads the record of what autonomy did: every run with its goal, status, receipt and timing. Only tick writes it; no verb replaces it.
- oko autonomy status — Reports the stored autonomy policy and every recorded run.
- oko autonomy tick — Attempts one bounded autonomous-goal execution under the saved policy.
serve#
- oko serve — Runs the one Oko process on a host: it owns the PTY broker in its foreground. Autonomy, the Slack responder, catalogue synchronisation and task handover are Oko routines Stado schedules (oko routines create --action autonomy|suggestions|index|control), not loops inside it.
- oko serve — The one Oko process on a host: it owns the PTY broker in its foreground. Everything that runs on a cadence — autonomy, the Slack responder, catalogue synchronisation, task handover — is an Oko routine Stado schedules, not a loop here. Run by launchd as the declared unit, it retires the launch agents whose work it absorbed; run by hand it never unloads the host's services.
calendar#
- oko calendar — Dispatches the calendar command group.
- oko calendar connect — Connects one of the user's own calendars: the macOS system calendars, Google Calendar, Microsoft 365, a CalDAV collection, or an ICS subscription.
- oko calendar accounts — Lists the connected calendar accounts without ever printing a secret.
- oko calendar disconnect — Removes a connected account and its locally synced events.
- oko calendar sync — Syncs every connected account (or one) over the window the caller names into the device-local events mirror.
- oko calendar list — Prints the upcoming schedule from the device-local mirror.
- oko calendar status — Reports connected accounts, the macOS consent verdict, and the store paths without prompting.
- oko calendar add — Creates one event on a writable account: EventKit, Google, Microsoft, or CalDAV.
- oko calendar edit — Changes named fields of one existing event; untouched fields stay as the provider has them.
- oko calendar remove — Deletes one event from a writable account and from the local mirror.
roadmap#
- oko roadmap push — Writes one roadmap item into work_items as a task contract for future work: what it promises, what the product already has, what it still lacks, and the acceptance that decides it is done.
- oko roadmap remove — Deletes one roadmap item, the inverse of roadmap push.
- oko roadmap list — Reads the roadmap task contracts Oko holds, so future work can be picked up from the store rather than from a conversation. The oko_roadmap_items MCP tool reads the same list.
- oko roadmap — Dispatches the roadmap command group.
- oko roadmap push — Writes a roadmap item: a task contract written before the work — what it promises, what the product already has, what it still lacks, and the acceptance that decides it is done — as one work item of the member's organization keyed by product and slug, so a second push updates it.
- oko roadmap remove — Deletes one roadmap item and its contract from the member's organization; the delete cannot be undone, so without --yes the item is named and nothing is written. An item that does not exist is reported, not refused, so a rerun is harmless.
- oko roadmap list — The roadmap items of the member's organization, by product and title, each with its contract.
- oko roadmap agenda — The research paper queue as the organization's work items, in the order the operator finishes them, each with the Lem roadmap projection lem-cli pushes into its metadata.
routines#
- oko routines — Dispatches the routines command group.
- oko routines create — Stores a typed Oko operation in Stado's durable schedule registry.
- oko routines list — Reads Oko-owned Stado schedules and their observed state.
- oko routines show — Inspects one retained schedule identity, including an uncertain creation.
- oko routines pause — Pauses future clock-driven occurrences.
- oko routines resume — Resumes future clock-driven occurrences.
- oko routines run — Submits one manual occurrence without changing the clock schedule.
- oko routines inspect — Reads Stado's actual job state and verifies its canonical Oko result.
- oko routines remove — Stops future occurrences and tombstones the owned schedule.
- oko routines execute — Runs the Oko operation a Stado schedule fired; this is the command every Oko schedule holds, not one to type.
- oko routines standing — Declares and enables Oko's continuous work on every installed machine: transcript catalogue and ledger, task control, released-defect reconciliation, reflection, and executor-supervision. The latter runs `oko sessions supervision run` under Stado. The model policy pass also remains in Oko's service, so waits can be settled and the improvement loop reads the declared signals even when the scheduler itself cannot answer.
defects#
- oko defects — Dispatches the defects command group.
- oko defects list — Reads the register: every defect, or only the open, the unplanned or the unrepaired ones, optionally of one product and one owner.
- oko defects category — Puts an item in the build-first pool: one whose repair decides the quality of all other work, because it gates delivery (CI/CD, install, push, the judge) or the rules agents work under (Tama's gates, supervision, stop loops). Product work — a new feature, a cleanup across a repository, anything a user of the product would see — is not in the pool, however urgent. `oko work` serves the pool before every other item, orphaned tasks included. While the operator's standing ban on building until every item is closed holds, his ruling that decides the item admits building, compiling, testing and installing it for its repair, and only it.
- oko defects show — Reads evidence, impact, source, plan, completion criterion or class inventory, measured remaining instances and failed operation, repair evidence, notes and related work.
- oko defects location — Prints the path of the register file this machine reads and writes.
- oko defects snapshot — Writes the open defects, newest first and in the shape `oko defects list --open --json` prints, to `<register>.open.json` beside the register (`defects.open.json` for `defects.json`). Every write of the register writes it too, under the register's lock, so a reader that may not start Oko — a Tama gate inside a harness hook — reads current open work from one file in milliseconds.
- oko defects record — Records one evidence-backed defect with an observable whole-repair criterion, or a class with a revision-bound inventory. The operator's decision bound to a Tama gate still prevents recording a defect against that gate, and a repair that needs an action `oko admit` refuses now is not recorded.
- oko defects note — Adds one dated observation to a defect, the way new evidence of a known defect is recorded instead of a second defect.
- oko defects retitle — Replaces a defect's one-sentence title when the first wording did not say what is wrong.
- oko defects found-in — Corrects the revision a defect was found in. A defect recorded after its repair was committed often names the repair itself as where it was found; a revision cannot repair what it is recorded as containing, so Tama's build gate counts such a defect as unrepaired until the revision that still had it is named.
- oko defects unordered — Lists the open defects whose recorded repair Tama's build gate cannot order after their found-in, so each can be read and corrected instead of staying counted as unrepaired.
- oko defects rebased — Lists each open defect's found-in, repair or attempted repair revision that a rewrite took off main, and the commit with the same patch. --apply follows claims without assuming the new commit was qualified.
- oko defects naming — Lists every open defect whose found-in, repair or attempted repair names one of the commits asked. The Git gate can see claims as well as verified repairs before rewriting history, and asks of every commit a move drops in one call, since Git holds the branch's lock while it asks.
- oko defects released — Lists the open defects whose recorded repair a published release already carries, and with --tasks the tasks it finishes; closes them with --close, so a batch release that published hundreds of repairs leaves none of them, and none of the work it finished, counted as open.
- oko defects linked — Lists every open defect with no recorded repair that a commit on origin/main names, with those commits, so a repair a session pushed and named in its message but never recorded is found instead of being repaired again.
- oko defects plan — Writes or replaces the complete repair plan: the mechanism that prevents the defect and the sweep that removes every existing case. A defect without one cannot be recorded as repaired.
- oko defects completion — Declares or replaces the complete-repair measure on a historical defect, including a class previously called repaired by one commit.
- oko defects assign — Gives one defect an owner or priority, or dispatches a selected product backlog to an executor in one locked register write. `oko work queue` reads the same owner field; the Desktop defect list uses the same native action. No selection silently takes another executor's work.
- oko defects shape-review — Inventories the source construct and same-shape siblings before a repair claim, so the executor identifies the shared mechanism instead of closing one instance.
- oko defects repaired — Measures the declared whole-repair condition at the committed revision before accepting a repair; publication still closes it separately.
- oko defects fix — Closes a defect with the published revision that contains its recorded repair, after asking Stado which releases of that repository exist; or, for a repair of one of the operator's own home documents (~/ARCHITECTURE.md, ~/NAMES.md, ~/STANDARD.md, ~/agents/*.md), which by his ruling live in no repository, with that document's SHA-256 as it is now.
- oko defects withdraw — Marks a defect as recorded in error: the product does not have it.
- oko defects reopen — Reopens a closed defect, withdraws a recorded repair, or takes back a withdrawal, keeping what had been recorded as a dated note.
- oko defects shape — Writes the shape a defect is one instance of — the design property that let it in — on a defect recorded without one, or restates it.
- oko defects shapes — Reads every shape the register holds with the defects recorded under it, the most recorded first, so the shape two defects share is read before the next fix of either.
- oko defects prevention — Declares where a new instance of a defect's shape is refused as it is made. Every defect the operator reported is repaired only as a class, and a class declares its prevention before its repair can be recorded.
- oko defects estimate — Records how many minutes the session holding a defect says its repair will take. The holder writes it once per take, when it takes the item (`oko work next --executor SESSION` or `oko defects assign <id> --owner SESSION`).
reflection#
- oko reflection — Dispatches the reflection command group.
- oko reflection observe — Retains an observed infrastructure failure before model assessment, even when Brama cannot answer.
- oko reflection scan — Reads operator and supervisor messages with ensuing agent work from Transcript Lake into Oko's durable model-judgment queue. No model call is needed for intake.
- oko reflection process — Asks Brama to assess queued transcript and infrastructure evidence and assign a shape to every unshaped defect.
- oko reflection run — Performs intake then processes the durable queue, as the standing reflection routine does.
- oko reflection list — Inspects transcript or infrastructure evidence, model assessment, defect link and pending cause without changing state.
- oko reflection signals — Dispatches the reflection/signals command group.
- oko reflection signals declare — Declares one factory signal: a measure over Oko's own registers, the level past which it is a finding, and the class defect it records, so a missing system is recorded before the operator has to name it.
- oko reflection signals standing — Declares the signals every installed Oko reads, as `oko install` does, so the improvement loop measures the factory on a machine where nobody declared a signal by hand.
- oko reflection signals list — Reads every declared signal and says what a pass would do, writing nothing.
- oko reflection signals pass — Reads every declared signal and records what it finds, as the improvement loop of every model policy pass does.
- oko reflection signals remaining — Prints the subjects past one signal's level, one per line: the completion probe of the class defect the signal recorded.
- oko reflection signals remove — Withdraws one declaration and prints it.
review#
- oko review — Dispatches the review command group.
- oko review scan — Reads every executor transcript from its retained cursor and files structural supervisor questions and every tool call of a measured low-standing executor, as the standing reflection routine does.
- oko review list — Prints every retained review entry, including watched low-standing tool calls with their source record, arguments and unanswered state.
- oko review answer — Types the supervisor's answer into the executor's terminal through the same defect-bound path as oko sessions send (as a redirect intervention), then keeps it on the entry with the terminal it reached.
instructions#
- oko instructions — Dispatches the instructions command group.
- oko instructions list — Prints the supervisor's submitted instructions to executors, newest first: one per target of every submitted defect-bound send (oko sessions send --defect --submit, the native terminal send, the standing supervision pass, review answers) and one for a new executor's first prompt from the standing supervision, audit or handover path. Typing without submission is a draft and creates no instruction.
- oko instructions show — Prints one instruction.
- oko instructions settle — Reviews what each executor did with the instructions still sent through Brama, as the standing supervision routine does after every pass.
- oko instructions retract — Supersedes an instruction in every terminal its send reached: each instruction of its batch not yet retracted is typed a retraction through the defect-bound path and marked retracted.
improve#
- oko improve — Dispatches the improve command group.
- oko improve run — Runs one pass of the improvement loop, as every model policy pass of Oko's service does: the factory's measures become work, the work is sent, and delivered work is measured again.
- oko improve status — Prints the last pass, how many passes are recorded, the candidates by verdict (pending, moved, notMoved) and the register path.
- oko improve history — Prints every recorded pass, oldest first.
- oko improve candidates — Prints every candidate: id, kind (capability, repair, optimization), title, defect, signal or entries, motivation, proof, recordedAt, dispatch, verdict and what was measured after its repair.
innovation#
- oko innovation — Dispatches the innovation command group.
- oko innovation propose — Records one proposal: the problem in words, the product that owns it, the measure that counts the problem, the figure it promises, its cost in executor hours and the operator's own words it answers.
- oko innovation list — Lists the innovations of a verdict and product, each with its effect: the baseline less the figure measured after its repair.
- oko innovation show — Shows one innovation by its id or the short form, with its effect.
- oko innovation edit — Changes a pending innovation's title, problem, promised figure, cost or sources; its baseline and quotes stay as read.
- oko innovation withdraw — Takes a pending innovation back, and withdraws its defect with the reason.
- oko innovation measure — Measures every pending innovation that is due, or the one named: its defect records its repair, a published release carries that repair (the delivery queue's register, `stado release newest --register`), so the figure is read where the change acts, and, for a measure over a window, that window has passed since the release.
- oko innovation derive — Has Brama propose innovations from every open frustration moment (`oko frustration list`) no recorded proposal cites yet, beside the declared signals and the forecast; each proposal goes through `oko innovation propose`, which reads its baseline and quotes itself.
blockers#
- oko blockers — Dispatches the blockers command group.
- oko blockers list — Reads the open blockers, or with --all every blocker ever recorded.
- oko blockers show — Reads one blocker: what it blocks, the failed operation, its exact error, the alternative tried, the resume condition, every check made on it and its resolution.
- oko blockers location — Prints the path of the blocker register this machine reads and writes.
- oko blockers record — Records one blocker with the evidence that makes it one: the task, defect or repository it stops, the operation that failed, the exact error, the alternative route tried, and the state of the world that resumes the work.
- oko blockers check — Records a dated check of an open blocker: it still blocks, or the state it waited on has arrived and the work it named is to be done.
- oko blockers reopen — Puts a resolved blocker back on the list: the inverse of a resolving check, for a condition that came back.
- oko blockers held — Names the open items a build itself unblocks: each item an open blocker holds while it waits (`--waits-on`) on an open defect whose repair is pushed. Only that build delivers what lifts the refusal, so `oko admit` does not hold a session's build on these items, and Tama's stop gate reads the same list.
- oko blockers idiotic — Lists the registered idiotic blockers — the false reasons to stop every session rediscovers — by how often they were raised, each with the fact that refutes it, so the reason an agent is about to give is read against its refutation instead of being repeated.
- oko blockers graph — Reads what waits on what across three registers at once and names the loops no single repair breaks, the critical path and how many items each node unblocks, so a chain of blockers is read instead of rediscovered.
- oko blockers roots — Answers the root causes of one item: every item its recorded waits lead to that waits on nothing, each with the chain from the item to it. A symptom (Brama refuses every model call) waits on a cause, which waits on another; each cause is recorded once as a waiting relation or a blocker's --waits-on, and this reads the chain instead of every session tracing it again. Only a root's repair moves the symptom.
work#
- oko work next — Answers the first item of one queue of all open work, the operator's tasks and the defects together, and why it leads. `oko work queue` shows the entire order.
- oko work queue — Answers the build-first pool, then the transfers of stopped executors' tasks, then every other open task and defect in rank order, with the reason for each item's place.
- oko work backlog — Answers the open items nobody owns, by product, and who could take them: each recorded executor (of one supervisor with --supervisor, else every one) with how many open items it owns, and one proposed assignment per executor, the least loaded given the next item of the product with the most unowned items.
- oko work progress — Measures how fast the open work moves, who moves it and who does not: the pool's remaining items, those claimed and unclaimed, the items moved (closed, or repaired and claimed while their proof waits) per hour and the time left at that rate, the measured repair norm, each executor holding pool items with its verdict, each model's moves per executor-hour, and the trend the model policy's passes kept.
- oko work forecast — Answers when the open work ends from the holders' estimates, so the answer does not fall silent when nothing moved, and when each release of the waiting graph unblocks.
- oko work resources — Measures what the agent sessions stood on over the window, and with --add N when the work would end with N more sessions, hosts like this one or subscriptions.
- oko work resources declare — Declares how many hours sooner the work must end before the operator is asked for a resource, and what each resource costs.
- oko work resources ask — Asks the operator, through `oko asks`, for each resource that would end the work sooner by more than the declared hours, with the gain and the declared cost; when the serial gates are the bottleneck the one ask is for their repair, since no added hardware speeds a gate up.
rulings#
- oko rulings — Dispatches the rulings command group.
- oko rulings list — Reads the ruling that stands on each subject — the newest operator message recorded as deciding that task or defect that no later decision of his superseded — for the named subjects or for every ruled subject, and beside it every ruling of those subjects a later decision superseded.
- oko rulings show — Reads one ruling: the subjects it decides, where and when the operator said it, his words verbatim, and the session that recorded it.
- oko rulings location — Prints the path of the ruling register this machine reads and writes.
- oko rulings record — Records one operator message, read from the session's transcript on this machine, as the ruling on the named tasks or defects, or on how every session holding a role works. The words are copied from the transcript, never typed in, and the answer quotes the words it bound, so a ruling bound to the wrong message shows at once.
- oko rulings unbind — Takes named subjects off one ruling that was recorded on the wrong task or defect: the inverse of binding them with record. The operator's words are not touched.
- oko rulings repeats — Finds every agent answer that named a ruled subject after the operator ruled on it, per subject, with the session, record and excerpt of each place; with --note, adds those places to a defect as one observation so repetition is recorded by the product.
- oko rulings enforce — Binds to one ruling the mechanism that now makes the corrected behaviour impossible to repeat: a Tama hook, a product command's refusal, or a real test, each by name and the product revision that carries it. A correction the operator gave once is answered once; the mechanism is what keeps it answered.
- oko rulings gates — Reads the installed Tama hook catalogue and shows the operator's transcript ruling bound to each hook in Oko. Reconcile reads actual standing-rule messages through Brama and binds only a verified decision; no Tama hook or installation is changed.
- oko rulings resolutions — Reads retained precedence decisions when a repeated operator standing rule defeats a lone contrary permission.
- oko rulings audit — Reads every standing ruling with the mechanism that enforces it, or `unenforced` where none is bound; with --record, each unenforced ruling becomes a defect of the named product whose repair plan names the enforce verb, so the missing mechanism is open work in the defect register until a session builds and binds it.
- oko rulings unlinked — Reads every genuine operator message of one session or every session with a user event in Transcript Lake, with the task that carries it, a related defect, or an explicit attachment to existing work. A ruling is visible context, not a substitute for a task or defect. An unread message, or one read before the session's first task, is carried by none unless attached explicitly; the text form refuses while any such message has no work link.
- oko rulings steering — Reads and changes who in the organization may record standing decisions that agents follow. Members and their central roles come from the organization's register, never from a list in Oko: an owner steers by role; any other member steers only through Oko's own grant of `steering.decide` in `oko_member_permissions`, which only an owner writes. The same authority decides which later decision may supersede an earlier one.
- oko rulings constraints — Every action and product a standing ruling constrains, each with the decision `oko admit` gives it now, every product's first.
admit#
- oko admit — The one decision whether an action class (build, compile, test, install or release) may run now, for one product or every product, and for the purpose the run serves; no gate or routine decides admission on its own. A ruling on `<action>` or `<action>:<product>` is the operator's consent; one on `no-<action>` or `no-<action>:<product>` withdraws it until a later ruling of his consents again. A consent scoped to a purpose, `<action>[:<product>]@<defect>`, admits only runs that name that open defect as their purpose, only while the defect is in the build-first category, and ends when the defect closes, after which the withdrawal it interrupted decides again. The newest applicable standing ruling decides. Where none decides a build, compile or test a session asks for (`--session`), the operator's standing rule decides it: the session's run waits until every open item carries its pushed repair — every open defect neither repaired nor kept as a claim, and every task the newest control pass owes without a repair (`oko tasks owed`) — except the items the build itself unblocks (`oko blockers held`). A run naming no session, such as a Stado routine or a pre-push gate, is decided by rulings alone; with no ruling, nothing constrains it. Stado asks it before a product operation that compiles (`build`), before a delivery publishes a release (`release`) and before its delivery routine installs; Tama's build gate asks it with the session for every compile, refuses a forbidden build quoting the ruling, admits one a ruling consents to, and refuses one the open-work rule holds with this reason unless the operator's build-consent answer or session capability admits it; Tama's pre-push `check-rust-format` and `quality-check` ask it for the pushed checkout and, under a withdrawal, run no tool and refuse no push; Oko's own grant-dialog settlement answers a waiting consent only when it admits; `oko defects record` and `oko defects assign` ask it for every action the defect's repair declares with `--needs` (assign with the defect as its purpose).
claims#
- oko claims — Dispatches the claims command group.
- oko claims record — Records a claim about work: a defect's repair at a revision, a pushed commit, a tool call serving its item. `oko defects repaired` records every repair this way itself, its author the session that owns the defect. `--stdin` records many claims, each with the verdict its recorder gave, in one write of the register: Tama's `review-push` records every commit it lets through this way, as a `push` claim on `<repository>@<commit>` with its structural verdict, in one call however many commits the push carries.
- oko claims verify — Records one verdict on a claim. A claim holds once the newest verdict of every kind its class needs holds at its revision: a repair needs the measure its defect declares — a real test (the criterion's journey report) for a single defect, a structural inventory for a class — and for a build-first item also an adversarial reviewer who tried to break it; a push a structural check of the pushed tree; a tool call a structural check and Brama's judge. A broken verdict breaks the claim. When `oko defects repaired` measures a repair itself, the passed measure is recorded as the claim's test or structural verdict, by `oko defects repaired: the declared completion measure`.
- oko claims review — Starts the adversarial reviewer a claim needs: a new agent session, as `oko sessions start` starts one, on a route that is neither the author's model nor provider, in the claim's repository checkout. Its first prompt hands it the defect (title, evidence, repair plan), the claimed revision and assertion, asks it to reproduce the original failure on the installed build, find inputs or states in which it still occurs, check the change removed the cause at every place the mechanism lives and that the real test exercises the product, and to record exactly one `oko claims verify <id> --kind adversarial` verdict from its own session, with no --by, --model or --provider: Oko reads those from the session running the command.
- oko claims show — Reads one claim: its class, subject, revision, assertion, author, standing and every verdict with who gave it, how, when and on what.
- oko claims list — Lists the claims, newest first, each with where it stands; --subject keeps the claims about one item, --unverified the ones that do not hold. `oko defects show` lists the claims about a defect, and `oko work queue` no longer serves a defect whose repair claim holds.
login#
- oko login — Request an email code, verify a code read in your own inbox, or run one explicitly selected autonomous sign-in method. No refused method is replaced by another.
logout#
- oko logout — Remove the shared session used by Oko commands.
database#
- oko database — Dispatches the database command group.
- oko database check — Connects to the shared Oko database as this person, resolving the database afresh through Stado, and says what every row will carry: the REST endpoint, the user id, the email and the organization — or the step that refused.
- oko database read — Reads the rows of one table in the signed-in member's organization, as that member's session may read them, and prints them as a JSON array; the organization filter is always added by Oko.
- oko database request — Sends one PostgREST request as the signed-in member and writes the answer's bytes as they came; with --body, the request body is read from standard input. Row security scopes what the member may read and write.
shame#
- oko shame — Dispatches the shame command group.
- oko shame list — Reads every wasted build: a build a model started without checking the code and the installation first.
- oko shame location — Prints the path of the wasted-build register this machine reads and writes.
- oko shame record — Records one wasted build against the model that started it and prints the penalty that model now carries.
- oko shame withdraw — Takes back one entry recorded in error — the build was consented to, or the check was made after all — so it counts toward no penalty: the inverse of record.
- oko shame penalty — Reads the penalty one model carries now: `none`, `check-before-build`, `no-build` with its end date, or `no-code`.
purgatory#
- oko purgatory — Dispatches the purgatory command group.
- oko purgatory list — Reads every session the operator gave his worst verdict on (a `verdict:worst:<session>#<ordinal>` ruling), held ones first, each with whether it is held, his verdicts in his words, its self-criticisms and the ones he took back.
- oko purgatory status — Reads whether one session is held: it is while a standing verdict of the operator on it is answered by no self-criticism of that session. Tama's `block-tools-in-purgatory` reads this before every tool call of a session.
- oko purgatory confess — Records the session's own newest answer, given after every open verdict and after any self-criticism the operator took back, as its self-criticism; the verdicts it answers stop holding the session. The words are copied from the session's transcript, never typed by the caller, so no session confesses for another.
- oko purgatory withdraw — Takes a self-criticism back: the verdicts it answered hold the session again, and only a new answer, given after this and not the same words, frees it. The inverse of confess.
- oko purgatory location — Prints the path of the purgatory register this machine reads and writes.
frustration#
- oko frustration — Dispatches the frustration command group.
- oko frustration list — Reads the recorded moments of operator frustration, optionally only the unanswered ones or one session's.
- oko frustration show — Reads one moment: the session and turn, the words, why it was read as frustration, how many earlier turns said the same thing, the cause named for it, the linked defect and the revision that answered it.
- oko frustration scan — Reads one session's operator turns for the moments he lost patience and records each: a turn Oko's model read as frustrated, or a demand already made earlier in the session. Reading a session twice duplicates nothing; `oko index sync` does the same for every session it rewrites.
- oko frustration record — Records one moment measured by hand, filed under the operator turn it names with the markers given (`recorded by hand` when none) and the repeats the recorder counted. Nothing a reading would measure is assumed, so two hand-recorded moments never land on one assumed turn.
- oko frustration cause — Names what caused the moment and, optionally, the registered defect it comes from.
- oko frustration answer — Records the revision that answered the moment's cause.
- oko frustration reopen — Takes an answer back: the revision named did not remove the cause, so the moment is open again with its cause still named. The inverse of answer.
- oko frustration settle — Answers every moment bound to a class defect once that class closes, and reopens it when the class is open again or finds its shape again; every model policy pass runs the same settling.
- oko frustration measure — The count over time of the operator's frustration, the factory's first measure, as each policy pass reports it under `frustration.measure`.
- oko frustration declare-relieving — Keeps one action the operator said lowers his frustration, in his own words, with the session and operator turn he said it in.
- oko frustration relieving — Lists every declared relieving action in the order declared, each with how many reliefs are recorded against it.
- oko frustration relieved — Records one moment a declared action lowered the operator's frustration, with his words.
- oko frustration reliefs — Lists every recorded moment of relief, newest first, with the action it is recorded against.
person#
- oko person — Dispatches the person command group.
- oko person assessment — Dispatches the person/assessment command group.
- oko person trait — Dispatches the person/trait command group.
- oko person show — Prints the whole model in one answer: how his own messages read on every declared dimension with his newest words behind each choice, how his decisions fared, what frustrated him and what he said relieves it, and what he said about himself.
- oko person assess — Has the model assess each operator turn of one session the register does not hold yet, on every dimension the product declares: whose words they are, whether an agent can act on them without guessing, whether they say when the work is done, how much of the method they leave to the agent, and whether they decide something and say why.
- oko person assessment list — Every assessment, newest message first, or those of one session.
- oko person assessment show — One assessment, named by its identifier or the eight characters every command prints.
- oko person assessment correct — Records a person's own choice on one dimension of one assessment. It stands over the model's choice in every count of `oko person show`, and the model's choice is kept beside it; the model never reads that message again.
- oko person decisions — How his decisions fared, read from the rulings register: each ruling of his with whether it still stands, what later decision of his replaced it and after how long, how many of his messages repeated the replacement, and whether anything enforces it.
- oko person trait list — Everything he said about himself, in his words, in the order kept.
- oko person trait show — One trait.
- oko person trait add — Keeps one thing he said about himself — how he works, what he values, what he expects of an agent — in his words, with the session and operator turn he said it in.
- oko person trait edit — Binds a trait to the turn he said it in: the turn he restated it in, with his restated words when they changed, or the right turn when it was bound to the wrong one.
- oko person trait remove — Removes a trait that no longer holds.
approvals#
- oko approvals — Dispatches the approvals command group.
- oko approvals list — Reads the approval queue: every item, only the open ones, or only the ones not yet delivered to their Slack thread.
- oko approvals find — Reads the approval item bound to one Slack thread.
- oko approvals enqueue — Adds one approval item, read as JSON from standard input.
- oko approvals bind — Binds an item to the Slack thread that carries its approval and opens it.
- oko approvals claim — Claims an open item for processing, so two readers of one answer cannot both process it.
- oko approvals finish — Ends an item with a final status, `resolved` when none is given.
- oko approvals reopen — Puts an item back to `open`.
requests#
- oko requests — Dispatches the requests command group.
- oko requests list — Reads the interaction requests the Requests screen shows: every one, or only the open ones.
- oko requests upsert — Adds or replaces one interaction request, read as JSON from standard input.
- oko requests close — Closes a request with a final status, `resolved` when none is given.
- oko requests reopen — Puts a request closed by mistake back on the Requests screen as open.
peers#
- oko peers — Dispatches the peers command group.
- oko peers status — Finds the Oko peers this LAN advertises over Bonjour (`_oko-sync._tcp`), the transcript mirrors already cached from them, and whether this machine holds the LAN credentials.
- oko peers sync — Mirrors every peer found on the LAN into its own cache directory.
- oko peers mirror — Mirrors every transcript one peer advertises into DIR: the signed GET /index, then a signed GET /file for each transcript whose size or modification time differs from the cached copy. A Codex transcript is kept under codex/<relPath> only when its path is relative, has no `..` and ends in .jsonl; a Claude transcript under <slug>/<id>.jsonl. Each written file takes the peer's modification time.
journal#
- oko journal — Dispatches the journal command group.
- oko journal claim — Claims one job for at-most-once execution in the executor's journal, kept in the shared Oko database so a job claimed on one machine is claimed on every machine.
- oko journal complete — Keeps the receipt, read from standard input, for the running claim of a job.
- oko journal fail — Records why the running claim of a job failed. A completed receipt wins when only a later artifact upload failed.
- oko journal undelivered — Reads the receipts of completed jobs not yet delivered, oldest job first.
- oko journal delivered — Records that a completed job's receipt was delivered.
asks#
- oko asks — Dispatches the asks command group.
- oko asks ask — Compares the complete proposed question and choices with the operator's standing decisions through Brama before it writes or redelivers an ask. An unrelated question is delivered on every channel the signed-in person chose (`oko contact`) and Oko Desktop or a watched Oko terminal on this machine. Each delivery records what its channel answered. An identical waiting ask is found rather than duplicated; a question no channel takes remains undelivered with each cause.
- oko asks list — Reads every ask put to the signed-in person, newest first, each with the state a reader acts on: waiting, undelivered (a waiting ask every tried channel refused — nobody was reached, and it is delivered again as a channel recovers), expired (a waiting ask past its time), answered or withdrawn.
- oko asks history — Reads every request put to the signed-in person, oldest first, with what came of it and what it was like, so whoever asks next reads what the person answered before, in their own words, beside the requests they answered and the ones they left.
- oko asks pleas — Reads every answer a session ended a turn on and the person's reply to it, newest first, with the ways the turn asked for something — so requests written in chat are read as well as those sent through `oko asks ask`, whatever form they took. No form of request is assumed: what the person accepts changes, and a reader that knows only an old form misses the current one.
- oko asks deliver — Before trying a channel again, compares the retained question with standing operator decisions as `oko asks ask` does; a settled request is not redelivered. Otherwise delivers a waiting ask on every channel that has not taken it, either by id or for every undelivered ask. Oko's service also retries when a channel returns and during task control.
- oko asks show — Reads one ask with every delivery attempt in the order it was made: channel, delivered or failed, and the channel's own words.
- oko asks wait — Returns once a waiting ask is answered, withdrawn or expired, so the product that asked can act on the answer given in Oko Desktop or Oko iOS. The change is learned from the database as it is written (Supabase Realtime on oko_operator_asks), not by asking again on a clock; an ask that already stopped waiting returns at once.
- oko asks answer — Answers a waiting ask once and records where it was answered. Oko Desktop answers with --on oko-desktop — from the sheet that opens when an ask reaches it and from the Requests screen — and Oko iOS with oko-ios; the product that asked reads the answer from the ask.
- oko asks withdraw — Withdraws a waiting ask: the product that asked no longer needs the answer.
- oko asks update — The hourly update the operator asked for, read from the registers and never written by a session: the questions waiting on him with their choices and the command that answers each, then the defects opened, repaired and closed since the last update sent (with how many are open and how many have no repair), then the open blockers with what each blocks and when it resumes. Oko's service sends it once per period of the schedule `update.json` declares (`@hourly`, the operator's ruling) on the `imessage` channel, so it reaches him without any session writing to him.
- oko asks announcers — Reads and changes the products whose asks only announce where an answer is given — Tama's grant window, answered in the asking session's own window — so `oko asks ask` records their ask and hands it to its own delivery instead of standing on the channels while the answer arrives elsewhere.
contact#
- oko contact — Dispatches the contact command group.
- oko contact show — Reads the channels the signed-in person chose to be asked on, in the order they are tried; Oko Desktop on the machine the ask is made on is tried as well, after them, whatever is chosen.
- oko contact set — Replaces the person's channels with the ones named, in that order: the one place how a person is asked is chosen. `oko-ios` is an alert on every iPhone signed in to Oko as this person; `imessage` is Oko's own, sent by Oko to the handle `oko contact imessage set` wrote, through the organization's Ultrareach, and also carries the hourly update; `mail` is Oko's own, mailed by Oko through the provider `oko contact mail set` declared, for a machine without Stado; every other name is a channel Stado pages through (`stado alerts channels`), handed in the same order to `stado alerts preferences set`, so Stado's pages and Oko's asks reach the same channels.
- oko contact clear — Removes every chosen channel; from then on an ask reaches this person only in Oko Desktop on the machine it is made on, and an ask made while Oko Desktop is not running there is refused to the asker as reaching nobody.
- oko contact mail set — Declares the provider Oko mails asks through itself, for the `mail` channel on a machine without Stado: the provider's send endpoint (a Resend-compatible `POST` taking `from`, `to`, `subject` and `text`), the sender, the destination and an owner-only file holding the key. Nothing of it is guessed, and the key file is checked now, before anything is written.
- oko contact mail show — Reads the declared mail provider.
- oko contact mail remove — Withdraws the declared mail provider; the key file is left where it is, and an ask on the `mail` channel is from then on a failed delivery naming the command that declares one.
- oko contact imessage set — Writes the signed-in person's own iMessage handle, the one place the `imessage` channel reads where to write: Oko's own channel, sent by Oko itself through the organization's Ultrareach (the messaging provider `oko message send` implements), carrying every ask and the hourly update. The handle is an Oko Desktop setting, so Oko Desktop's Requests screen (iMessage from Oko itself) and this command hold one value.
- oko contact imessage show — Reads where the `imessage` channel writes and through which relay, each part with where it was read from.
- oko contact imessage send — Sends one message on standard input to the person's handle the way an ask or the hourly update is sent: to check the channel end to end.
stats#
- oko stats — Dispatches the stats command group.
- oko stats snapshot — The numbers Oko Desktop's activity screen shows: tokens used (input, output and cache writes; cache reads are left out), operator prompts and frustrated prompts over the last day, the last week and all time, the agents and projects the frustration came from, and the conversations touched in the last day.
- oko stats models — Which model does the work, best and fastest: one row per model with the agent time active on it, the tasks judged done and the defects repaired or closed while a session ran it, the tasks reopened afterwards, the median time from a task's operator message to its done verdict, agent time, tokens and cost per item and per done task, the median time from a defect's assignment to its repair, and the quality of that work — repairs taken back, records withdrawn as made in error, defects later found in its commits, and pushes refused against commits made. Oko Desktop's Activity screen shows the same table under Models, with a field for the hours, and the model policy reads it.
diff#
- oko diff — What changed between two revisions, per file and hunk, read from `git diff BASE..BRANCH`.
terminal#
- oko terminal — Dispatches the terminal command group.
- oko terminal install — Installs the terminal the live-terminal pane drives, so nothing is downloaded by hand. With Homebrew it is `brew install --cask ghostty`; without it the pinned release disk image is downloaded, mounted, its Ghostty.app copied into ~/Applications and the image detached. Every step is printed as it happens.
- oko terminal uninstall — Takes the terminal back the way it came: the Homebrew cask through `brew uninstall --cask ghostty` when Homebrew owns it, otherwise by removing the Ghostty.app Oko copied into ~/Applications. A bundle elsewhere that Homebrew does not own was placed by somebody else and is left alone, by name.
message#
- oko message — Dispatches the message command group.
- oko message send — Creates one iMessage chat through the named messaging provider, with the text from standard input, and prints the chat the provider created.
repositories#
- oko repositories — Dispatches the repositories command group.
- oko repositories execution — What an organization has been building, from the named code host: its most recently pushed repositories, each with its description, recent commit subjects, top authors, days since the last push and each author's commit times.
index#
- oko index — Dispatches the index command group.
- oko index sync — Brings this person's transcript catalogue in the shared Oko database up to what Transcript Lake holds. The text comes from Lake, already masked; changed sessions are read newest first. Identical retained Lake events count once when building searchable conversation text and classifying recorded repairs. Each rewritten session also has its frustration moments recorded.
- oko index list — This person's catalogued sessions, newest first, or with --query ranked by the database's full-text search with a context snippet. Every filter named narrows the one list, so a directory since a time, or a search in one directory, is one call.
- oko index count — How many sessions the catalogue holds for this person.
- oko index coverage — How far the catalogue covers what Transcript Lake holds: what was read at the detector's current version and what was not, and which Lake sessions with operator messages the catalogue lacks or counts short.
- oko index owners — The owners the catalogue records sessions under.
- oko index prune — Removes the catalogue rows of sessions Transcript Lake no longer holds.
- oko index occurrences — Counts every message that says WORDS: per session and in total, with each message's session, record number, speaker, time and an excerpt. `oko index list --query` answers which sessions match; this answers how many times.
lake#
- oko lake — Dispatches the lake command group.
- oko lake survey — Describes the transcript roots on this machine: which runtimes wrote where, how many files and how recent.
- oko lake sources — What Transcript Lake can read on this machine, asked of Lake's own CLI; Lake owns the list of runtimes and Oko keeps no copy.
- oko lake adopt — Has Transcript Lake ingest one source, then brings the shared catalogue up to it with `oko index sync`.
onboarding#
- oko onboarding — The first-use journey: the declared screens, this machine's private progress under $XDG_STATE_HOME/oko/onboarding.json (else ~/.local/state), and completion recorded only after Transcript Lake accepted a source and the shared catalogue was brought up to it.
ledger#
- oko ledger — Dispatches the ledger command group.
- oko ledger sync — Carries this machine's task ledger from a local transcript index into the shared Oko database, every row as the signed-in member's. A table read from transcripts is upserted; a table Oko's commands write is only seeded, so an older index never replaces a row recorded since; a table whose rows live writes retire is carried under the live write's lock.
- oko ledger show — One session's task ledger as the shared database holds it: each task with the session's statement, evidence, the judge's verdict or outage, the contract and the relations it takes part in.
oneoff#
- oko oneoff — Dispatches the oneoff command group.
- oko oneoff list — The one-off repairs `oko index sync` recorded: for open sessions, named sessions, or every session, optionally one category or only those no later successful commit followed. Every answer carries how many sessions the detector has read at its current version, so a zero from an unread catalogue is not a measurement.
- oko oneoff window — The one-off repairs recorded in a time window.
- oko oneoff categories — The categories of one-off repair, each with its meaning and the route that owns it.
- oko oneoff rules — The rules the detector applies, each with its category, route, example and whether a Tama gate refuses it before it runs.
- oko oneoff check — Runs every rule's example past each gate the installed Tama registry binds to a bash payload and reports what each refused. A gate that refuses the control command `echo ok` is answering about this context, not about a shape, and is reported apart.
release#
- oko release — Dispatches the release command group.
- oko release submit — Hands one source revision to Stado's batch qualification (`stado release changes submit`), which alone verifies remote ancestry and writes the immutable receipt; Stado's JSON is passed through.
- oko release list — The receipts Stado has written for Oko's handoffs (`stado release changes list`).
- oko release surface — Oko's public command surface, read statically from rust/src/main.rs — the commands `oko help` advertises — from a checkout or from the tree a revision names; the version gate compares it with the released baseline. An unreadable help surface is a refusal, never a shorter list.
- oko release baseline — Derives released-surface.json from the best reachable published artifact — a GitHub Release above a tag's git archive above HEAD — trusting a tag only when the remote names the same commit for it and a Release only when it carries an asset named for its version.
planning#
- oko planning — Dispatches the planning command group.
- oko planning publish — Writes the planning state the suggestions tick computed — assignments, plans and cost on standard input — to the member's organization in the shared database with their own session. Every row is stamped with that organization; a row naming another is refused rather than moved.
subscriptions#
- oko subscriptions — Dispatches the subscriptions command group.
- oko subscriptions snapshot — Which subscriptions this machine's agent has and what they cost. The model router, asked signed as Oko through Brama, is the source of truth together with the Weles subscription service; the local cost catalogue is read only when the router is not configured.
strategy#
- oko strategy — Dispatches the strategy command group.
- oko strategy load — Prints the signed-in member's organization's company strategy document, read from company_context and its lists with the member's own session, and keeps it as the local strategy cache the Slack agent reads.
- oko strategy apply — Applies a company strategy document, read from standard input, to the member's organization through the database function that owns the write.
install#
- oko install — Installs this build, natively signed through Stado's product signing, over the installed one, links it on PATH, and has the installed build serve new terminals at once while the replaced service keeps only the terminals it started.
version#
- oko version — Prints the release this binary was built as, read from release/VERSION when it was compiled. Stado delivers oko as a managed binary and reads this line to confirm a host runs the version it declares (stado release version promote --host HOST --binary oko --version V, then stado release version converge --host HOST --binary oko).
mcp#
- oko mcp — Dispatches the mcp command group.
- oko mcp serve — A read-only Model Context Protocol server on standard input and output, one JSON-RPC message per line: the newest and matching catalogue sessions, the roadmap task contracts, and the organization's roster, goal snapshots and work telemetry, every one read from the shared database as the signed-in member. Nothing is written; standard output carries protocol frames only.
agent#
- oko agent — Dispatches the agent command group.
- oko agent run — Runs one prompt through a coding harness behind the local Brama proxy with the routed overlay, printing its events as they arrive. ID is a harness id from the catalogue `oko agent harnesses` lists — the same id Transcript Lake and Tama use. The harnesses Brama can route are Claude Code (`claude`), Codex (`codex`), Kimi Code (`kimi`), Qwen Code (`qwen`), OpenCode (`opencode`), Goose (`goose`) and aider (`aider`); every other harness in the catalogue is refused with the sentence saying why. Claude Code and Codex stream JSON lines in their non-interactive modes, Kimi Code speaks the Agent Client Protocol, and the others print text, one event per line. The events are the run's session, words, tool calls, results, end and errors; its reasoning (Claude Code's thinking blocks, Kimi Code's thought chunks) is never printed or written, with or without --json, and a thinking line read back from an older remote Oko is dropped, since reading another model's reasoning is what model providers refuse as extracting it.
- oko agent harnesses — Lists every coding-agent harness Oko knows — the catalogue `oko agent run`, `oko sessions adopt` and the activity counts read — and reads each against this machine: whether its program is installed, whether Brama can route it and why not, whether `oko agent run` can start it, and which of its transcript directories exist. Transcript Lake reads the sessions of the same harnesses under the same ids. Catalogue-based Codex resumption uses `codex resume <session>` without bypassing hook trust; the harness keeps its own trust requirements.
proxy#
- oko proxy — Dispatches the proxy command group.
- oko proxy serve — The local Brama proxy: a listener on this machine's loopback address that a harness talks to as if it were a model provider. Each request must present the listener's capability token as Authorization: Bearer or x-api-key; the proxy relays /v1/chat/completions, /v1/messages, /v1/responses and GET /v1/models to Brama with Oko's bearer and body-bound signature, and Brama's streams, tool events, usage and refusals come back byte for byte.
- oko proxy sign — The three agent headers Oko signs a request with — id, signature and timestamp — for a body and a time, so another process can present Oko's identity to Brama.
- oko proxy translate — Translates one provider-shaped request body into the chat-completions body the proxy would relay, so a translation can be read without a listener.
tasks#
- oko tasks — The ledger of what the operator asked for: each request as a task with its contract, evidence, relations and Oko’s independent verdict. Oko Desktop, Tama’s gates, the control routine, a session and the operator read and write the same ledger through this one group.
- oko tasks messages — Prints every operator message of a session, in order and verbatim.
- oko tasks control — Puts every session that still owes the operator something back to work on exactly that, in one pass; the Oko routine with action control repeats the pass for as long as the Oko service runs.
- oko tasks verify — Judges the recorded result through Brama and saves an independent verdict for each open task, including before a running session stops; while the judge does not answer, each task's attestation decides and the judge's verdict stays owed.
- oko tasks rules — Prints the operator’s standing rules from every session in scope, in the operator’s words.
- oko tasks unread — Lists stored operator messages without a reading. Classification coverage is distinct from linking every message to a task.
- oko tasks list — Lists operator requests with their independent verdict and derived completion standing; a done verdict without qualified source and observed result remains an open claim.
- oko tasks owed — What a build still waits on, in one shared-database read: the open tasks that carry no commit or report as their repair, as the newest control pass recorded them, and the open defects with no recorded repair.
- oko tasks show — Shows one task by its identity: the object, what its origin session’s ledger says about it now, its defects and the task it repairs.
- oko tasks close — Records the operator's own completion verdict without a model. It cannot bypass source-bound behavioral qualification; unsupported done remains claimed and open.
- oko tasks kind — Records what one operator message is to the ledger, with the kinds Oko’s model reads from, when the model has not read it or read it wrong. Many messages are about one piece of work, so only `task` starts a task.
- oko tasks add — Records an operator message Oko’s model did not read as work as the task it is, or, with --part N, one of several instructions in one message as a task of its own, so its name, statement, contract, status and relations can be written like any other task’s.
- oko tasks read — Has Oko’s model read what each operator message is to the ledger, for the messages that have no reading yet, oldest first.
- oko tasks claim — Transfers the task's leading session, including an orphan whose previous executor stopped.
- oko tasks state — Records a task’s contract beside the operator’s own words: its name, what it asks for, the checks that decide it is done, how long it is expected to take, its priority and due date, the repositories it may change, which parts of the Jeden task contract apply to it, what blocks it, and whether the operator confirmed it, so a message that points at its turn still describes the work to a later reader and to the judge.
- oko tasks check — Records whether one acceptance check of a task’s contract is met, with the evidence that shows it, so a reader sees which check holds instead of one verdict over the whole task.
- oko tasks evidence — Records evidence for Oko’s independent completion check without asking the operator to close the task manually.
- oko tasks submit — Records a pushed source handoff for later shared build and behavioral qualification, without starting a build or finishing the task.
- oko tasks qualification — Refreshes later batch verdicts and reopens the author task when a covered build fails.
- oko tasks defect — Reopens a task for repair; an old acknowledgement or verdict cannot close its defect.
- oko tasks relate — Records duplicate-of, follows, blocked-by or part-of by identity; a task or defect may be part-of a current operator goal.
- oko tasks unrelate — Removes a recorded relation between tasks, defects or an operator goal.
- oko tasks relations — Lists one task’s relations from its own side, with the other task’s state and what this task waits on.
- oko tasks map — Shows a tree of recorded tasks and defects under each current operator goal, with unlinked and unjudged work as graph debt. Select --place open for the open backlog; it is a filter of this map, not another command.
- oko tasks graph backfill — Places recorded tasks and defects under operator goals and asks Brama to judge duplicate-of or follows using quoted evidence.
- oko tasks derive — Derives the operator's messages and tasks from one named session (Transcript Lake before a local live copy), an explicitly named transcript, or every session with a user event in Transcript Lake, bound to canonical identity allocations. Every derive reads the signed-in member's shared database; --write also stores messages and tasks.
- oko tasks link — Attaches a genuine operator message to an existing task or registered defect without changing its reading. Use this for a historical question, consent or correction about existing work, rather than inventing a new task from it.
- oko tasks unlink — Removes an explicit message-to-work attachment recorded on the wrong task or defect; it leaves the source message, task reading and any ruling untouched.
- oko tasks links — Reads the explicit current message-to-work attachments for one genuine operator message without writing anything.
- oko tasks report — The same session's tasks settled against everything recorded against them in the shared database: claims, evidence, verdicts, outages, relations. With --list, an array for every named session and, with --open, every live session written in the last hours, newest first — the form `oko` and Oko Desktop read.
- oko tasks snapshot — Settles one session's open work as `oko tasks --open --session ID --read-only --owed --json` answers it and writes it to `~/Library/Application Support/Oko/open-work/<ID>.json` (OKO_OPEN_WORK moves the directory), so a gate inside a harness hook reads it in milliseconds instead of settling the sessions itself, which takes longer than a harness waits for a hook.
- oko tasks sweep — Writes the ledger again for every session on this machine whose live transcript changed since its ledger was last written, or whose ledger was written before the running Oko was installed (the reader compiled into an Oko decides which turns are the operator's, so a new release re-derives every ledger once), newest first, so the shared ledger follows the transcripts, and removes from every session's stored messages the turns no operator typed.
- oko tasks health — What the handover is doing right now, on one screen: every session that owes the operator something — its open tasks, when it last wrote, whether it is working, held by somebody's own window, refused by the model, has answered exactly its list or is due again, how many of its tasks are being diagnosed or blocked — with the totals, the model's refusal when it refuses everyone, and the last control pass with its failures, its stages and the stage it still stands on.
- oko tasks handover — One handover pass: every session owing the operator work is handed its list.
- oko tasks answer — The newest turn's prompt, answer and tool evidence — exactly what the independent judge is given — for one session.
- oko tasks judge — Reads the saved model observation, or explicitly asks the selected judge service and persists the result.
- oko tasks verdict — The judge's verdict, bound to the task as it stands. A not-done or blocked after either counts one more round; done starts the count over; blocked must carry a blocker file that names this task; withdrawn says the task is no work owed and only the operator, the session the message was given in, or a session quoting the operator's own words from its transcript may record it. A verdict ends the task's outage; one --by operator is confirmed on the terminal it runs from.
- oko tasks outage — Records that the judge could not answer for this task — by the product, not the agent — so the task waits on the judge rather than being read as unanswered work.
- oko tasks held — Answers the tasks a session claimed in the shared ledger and has shown nothing for: no evidence recorded and no verdict of done. Tama's block-stop-with-claimed-work asks it to refuse ending a turn of that session while any is left.
- oko tasks carried — The tasks whose recorded evidence names one of these commits. A batched build carries commits, not tasks: `tama build pending` shows which tasks ride on the next build of a product, and `tama build fail` reopens exactly these when that build fails. Evidence written with a `<repository>@` prefix or abbreviated is matched on the revision.
model-service#
- oko model-service — The model service every model call Oko makes as itself asks.
- oko model-service show — Which model service Oko asks as itself: Brama by default, the OpenAI-compatible chat-completions service — OpenAI, OpenRouter, a local server — this machine declared, which the judge, the reading, `brama complete` and `oko gateway send --prompt` ask with its declared model, or no model at all, so tasks are judged and Tama's guards answered where Brama is not installed.
- oko model-service set — Declares the OpenAI-compatible service Oko asks instead of Brama, or that this machine has no model.
- oko model-service clear — Removes the declared service, so every model call goes to Brama again.
api#
- oko api — Dispatches the api command group.
- oko api status — Reads the native API version, broker protocol, process identity and executable of the running Oko service, and refuses unless the service speaks this build's native API and PTY broker protocol.
- oko api call — Sends one structured native API request to the running Oko service and prints its actual result.