Voice OS commands

Everything you say to Voice OS goes through the kernel, a small, fast model whose only job is to decide what your words should do. It has a fixed set of tools, one for each thing it can do: pass your words to a session, switch the screen, answer a permission, take a note, and so on. This page lists every tool, with things you can say to reach it and what happens next.

You never name a tool. Speak the way you would to a colleague; the phrases below are examples, not commands to learn. Any language you speak works the same way (see Languages). For the bigger picture, read the Voice OS guide.

Contents

How your words are routed

Talking to sessions

Send words to the session on screen — forward

The default on a session's screen. Your words go to that session's Claude exactly as heard, never reworded. A session that isn't running starts by itself.

What happens: the words appear in the session's stream, and Voice OS reads its reply when it ends its turn. While the session is working:

In practice:

Send words to another session — send_to

The same as forward, for a session you name, without leaving the one you are on.

What happens: "Sent to checkout. Switch there?" Yes switches; anything else keeps you where you are. A short answer is said at once, with the session's name; a longer one comes later in the meanwhile line.

In practice:

Change words already queued — queued_message

Acts on words that wait in a session's queue, or that it just received.

In practice: it acts on your last words for that session. The page's ▲ now and ✕ cancel buttons do the same by click.

Stop the current work — interrupt

What happens: the session's current turn ends and it keeps everything up to that point. The session stays active, and you can carry on with it.

In practice: a bare "stop" interrupts the session on screen, never one you are not looking at. "Stop the refactor and fix the login bug first" names what to do instead, so it is a redirect sent with forward, not an interrupt. Off a session's screen, with a session working and none named, Voice OS asks which one.

Moving around

Show a session, Active or Activate — switch_view

What happens: Voice OS says "Switching to checkout" first (a click is silent), and that session's update, if it had one waiting, plays when you get there. When the sentence also asks the session for work, that part goes to it once you are there, and you hear "Sent to checkout". A longer sentence that asks for work in a place ("go to the research folder and check what's in there") goes to the session on screen instead.

Go back — go_back

What happens: "Back to crew." Say it again to go further back. Sessions that stopped are passed over ("checkout stopped. Back to crew."). "Go back to checkout" switches to checkout, and "go back to crew research" finds crew research even when crew main is named "Crew"; "home" means Active. Words that also ask the session for work reach the session you land on.

Hear what you missed — play_missed

What happens: the other sessions' updates that were waiting for a quiet moment play now, as one line ("Meanwhile, ranking needs you about the index, and checkout said: all retry tests pass"), or you hear that nothing is new. Clicking N updates waiting in the top bar does the same. A plain "yes" right after "Switch there?" answers that question, so it switches instead of replaying.

Active sessions

Only active sessions exist for voice (see Active sessions).

Activate a worktree — activate

What happens: "Activated checkout. Switch there?" Its Claude starts and resumes its conversation. On its own screen you hear just "Activated checkout." (no screen to watch over Discord). If two worktrees match, Voice OS asks which one.

In practice: "Start checkout and tell me what it did last" activates it, then sends it the rest once it is up. Activating never creates a worktree: make one in Set up. A setup session is never activated; it runs by itself for Set up's chat.

Deactivate a session — deactivate

What happens: its Claude stops, and Voice OS drops what it held for it (queued words, questions, updates). The conversation is kept for the next activation. If the session is working, you are asked first: "checkout is working. Deactivate anyway?"

Ask what there is — list_sessions

What happens: counts first ("Build box has 11 worktrees in 6 workspaces; none active"), then names when the list is short. These are answered even on a session's screen. "What's running in the tests?" is about the work, so it still goes to the session.

Start a plain Claude session — new_session

What happens: "Started research." A plain session is a Claude conversation of its own, not a worktree: it runs in the folder you name on that machine (your home folder when you name none), with no crew instructions and no dev servers. It is active at once and starts a few seconds later; talk to it by its name like any session. A folder that does not exist there is refused, never created.

In practice: the same as New session on the Activate page. Renaming works like any session's ("call research the reading list").

Remove a plain session — remove_session

What happens: "Removed research. Its folder stays." Its Claude stops and it leaves your lists; the folder and its files are never touched. One that is working is asked about first. Worktrees are never removed by voice: deactivate stops one, and Set up removes it.

Answering what waits on you

Answer a permission, plan or question — answer

What happens: the session continues with your answer, and the dock on the page closes.

In practice:

See Questions, plans and permissions.

Let a blocked call through once — allow_denied

What happens: when auto mode blocked something (the red blocked strip), that one call goes through and the session retries it. Auto mode is back for the next call. See Auto mode and approvals.

Accept or decline a dev-server fix — dev_offer

When a dev server dies, Voice OS asks whether Claude should fix it.

What happens: yes hands the worktree's session the failure with its log; no lets it go.

Asking how things are

Sessions right now — read_state

What happens: a short spoken answer. Voice OS looks at the sessions (status, what each was last asked, what waits on you, their latest lines) and answers in a sentence or two. An answer about one other active session ends with "Switch to checkout?", so a "yes" takes you there.

In practice: this is for sessions you are not looking at. "Status" or "how far are you?" on a session's own screen goes to that session, because it knows its work better than any summary. Even when Voice OS reads that session first, the words still go to it, unless they are for Voice OS itself, such as "repeat what it said".

A recap of what happened — status_update

What happens: a short spoken recap of the last hour (or the time you name): first what waits on you ("checkout asks: push to main?"), then what each session got done, then what is still running, each session by name. It is written when you ask, from the turns Voice OS recorded and the updates you have not heard, so nothing runs in the background. The updates it covers are heard: the meanwhile line does not say them again.

In practice: made for when you are away from the screen, over Discord or a closed page. A bare "status" or "how far are you?" on a session's own screen still goes to that session, which knows its work best. Without an Anthropic key, or if the recap is slow, you hear a plain version: what waits on you, then each session's latest line.

Past turns — read_history

What happens: Voice OS searches the turns it recorded, across restarts, and answers briefly. Only off a session's screen: on one, the session remembers its own past.

Dev servers

Start, stop, restart or check them — crew_dev

What happens: Voice OS runs it through crew on the worktree's own ports and says how it went: which server died, and which never started listening. If one fails after a start, it offers a fix (dev_offer).

In practice: "Why were they failing? Check the logs." is work for the session, which reads them with crew dev logs. See Dev servers.

Notes and debug notes

Take a note — note

What happens: "Noted." The note goes to the workspace on screen, the one you name, or your general notes off a session's screen.

Read notes back — read_notes

What happens: a brief read-back, newest last. "Go through my notes and pick one to build next" is work, so the session reads the file itself.

Flag Voice OS going wrong — debug_note

What happens: "Debug note saved." Your words are saved with a snapshot of this moment, next to Voice OS's log. Read them with crew server debug-notes. See Notes and debug notes.

Docs

Open a doc a session made — open_doc

What happens: it opens in the browser tab you spoke from. If the browser blocks the new tab (phones usually do), a banner offers the link.

In practice: only docs the session listed. "Show me the diff" or "add a section on risks to the doc" is work for the session.

Names

Name a session — rename_session

What happens: the name shows everywhere and Voice OS answers to it. "Rename the function to parseRef" is work, so it goes to the session, and a name-like phrase heard inside other words ("commit directly to main and release") renames nothing. See Session names.

Name a machine — rename_machine

What happens: the machine is shown and spoken by its new name. Only with other machines set up.

Voice OS itself

Change how this tab listens — hands_free

What happens: Voice OS confirms the mode aloud ("Hands-free."). A bare "stop" or "wait" is never this: those interrupt. See Listening modes.

Quiet — mute

What happens: what Voice OS had queued to say is dropped, and its routine narration stops. Sessions' own lines, questions and alerts still play.

Words that want nothing — ignore_words

What happens: nothing, and nothing is said. A bare "yes" or "sí" right after Voice OS's own "Switch there?" is never ignored: it answers the offer.

In practice: filler in front of a request doesn't count ("hmm, let's start this" is a request), and a question is never ignored. Thinking out loud about the work goes to the session.

Words that never reach the kernel

Some words are settled before the kernel sees them:

Previous
Set upNext
How crew works