The conversation

quox with no arguments opens the conversation.

quox
quox -p staging -n release-checks
quox --verbose full

Option	What it does
-p, --profile <name>	Use a signed-in profile. A profile that does not exist is an error, never created on the fly.
-n, --name <name>	Name this session. See Sessions and agents.
--verbose off|on|full	How much protocol detail to show. Bare --verbose means on.
--demo	Play a simulated journey. No server, nothing real runs.
--no-clear	Do not clear the screen on start.
--service-key	Allow an ambient QUOX_SERVICE_KEY when the profile has no login. Never used without this flag.

Type a message and press Enter. CommanderQ, the default agent, routes it to the right specialist. Type /help for the list your version supports, or /help esc for detail on one key.

Depends on how your QuoxCORE reaches its model

On some provider paths the server does not send tool events yet, so tool lines and the AEE, AOCL and WARD lines below may not appear, and steering is not applied. Approval cards still appear on every path: Quox checks for pending approvals every 4 seconds. A fix is in progress; this note goes when it ships.

Keys

These tables are generated from the client’s own /help registry, so they match what your terminal shows at this version.

Talk

Key	What it does
just type	ask Quox anything; CommanderQ routes it to the right agent
Enter	send; while Quox works, steer the running turn if this server supports it, else queue it Idle: sends. During a turn: steers when the server supports it (shown here once known), delivered at the next model boundary (never kills a running tool). If the server cannot steer, or the turn already finished, it is queued instead and you are told.
Tab	queue your message to run after this turn Queued messages show above the composer. Up (empty composer) pulls the last one back to edit. After an interrupt they wait; press Enter on an empty composer to send the next one.
Esc	ask the server to stop the turn (idle: Esc Esc clears the draft to history) Asks the server to stop before the next model call or tool; you see "stopping" until the server confirms. A tool already dispatched finishes and is reported, never hidden. Until the server route exists the stream is aborted locally and you are told work already sent may still finish.
Shift+Enter / Ctrl+J	new line in the composer (a trailing \ then Enter also works)
Ctrl+G	edit the draft in $EDITOR
Ctrl+S	stash the draft; on an empty composer, restore it
Ctrl+_	undo in the composer
paste	long pastes collapse to [Pasted text #N +L lines] and expand on send
Ctrl+C	clear the draft; during a turn interrupt; twice when idle quits
!<command>	run a shell command here without leaving (!quox <args> runs this quox as you); output stays on your screen A line starting with ! runs on this machine in the current directory via your shell and prints inline: "$ <command>", the output, then "exit N". It is never sent to Quox, starts no turn and needs no approval, because it is your own command. !quox <args> (or !q <args>) runs THIS quox binary with your current profile, so !quox inbox list works as you; bare quox and tui need the terminal and are refused. Ctrl+C stops it (SIGTERM, then SIGKILL after 2 s) without quitting; one command at a time; stdin is closed, so a command that waits for input gets end-of-file; 120 s limit (QUOX_BANG_TIMEOUT_MS); output is capped at 2000 lines / 256 KB. !! is reserved. Only the command line and exit code go in the dev transcript, never the output.

Context

Key	What it does
status line	profile · org · agent · model · mode, under the composer
@mention	complete agents, hosts, tasks and receipts as you type @ Type @ at the start of a word: a list under the composer suggests agents, fleet hosts, tasks (your newest objectives) and receipts (the envelope ids of this session's tool calls), filtered as you type by id or name. Tab or Enter puts it in, Esc closes the list. The lists are fetched once per session on your first @ and then filtered locally, so typing never sends a request; receipts come from this session and need no request at all. /peek <id> shows what an id is.

Generated from the quox client registry at 8210595d6 (quoxcli 0.3.1).

Enter while Quox is working. It steers the running turn when your server supports steering, delivered at the next model boundary, and never kills a running tool. When the server cannot steer, or the turn has already finished, your message is queued instead and Quox tells you so.

Esc. It asks the server to stop. You see “stopping” until the server confirms. A tool already dispatched finishes and is reported, never hidden.

After each turn a grey summary line shows how long it took, how many tools ran and how many approvals it raised.

/quit (or /exit) leaves. Work already sent to the server keeps going.

Slash commands

Talk

Command	What it does
/share [N]	attach the output of your last ! command (or the Nth-last) to your next message Command output is not shared with Quox by default, because it can contain secrets. /share attaches the latest ! result to your next message (up to 16 KB, and it says when it was cut); /share 2 picks the one before. A line "shared with Quox: output of `<command>`" appears when it is sent.

Approvals

Command	What it does
/approvals [mine|agents|old|<agent>|N]	the questions waiting for you, one at a time
/walkthrough	walk through what is waiting for you one question at a time: what it does, why, my advice, then your choice (same as /approvals walkthrough)
/yestoall	approve everything waiting for you (same as /approve all; privileged ones still ask)
/approve N | 1 y 2 n | agent <name>	approve item N from the list, or everything one agent asked Run /approvals first. Mid-turn approval cards also take a (approve), d (deny), o (open); they arm after 300 ms and never default to approve.
/deny N [reason] | agent <name> [reason]	deny item N (or all of one agent) with an optional reason the requester sees
/answer 3 b ["note"] | 1 y 2 n	answer a decision a session asked (quox ask): pick its option, with an optional note the asker gets Run /approvals first: decisions are listed first, one line each, with who asked, the options (a) (b) (c), what is recommended and how long is left. /answer 3 b picks option b of item 3; /answer 3 b "after Friday" adds a note. After /approvals 3 you can leave the number off: /answer b. y/n questions also take /approve 3, and /deny 3 <reason> declines with a reason. /approve all never answers a decision for you.
/authenticate	enter your PIN once: a person is present for 10 minutes A typed y cannot prove a person typed it, so approvals an agent raised (or high-risk ones) and /override need your step-up PIN. /authenticate asks for it once and keeps a "human present" window open for 10 minutes (shown in gold above the status line), so those do not ask again. Set the PIN in the dashboard (Settings > Account > Approval PIN); it cannot be set from here. Agent logins cannot use this: a person approves from their phone or a human session.
/authorise N also /authorize	approve item N with your PIN Like /approve N, but asks for your step-up PIN first when there is no live human-present window. The digits are never shown, saved, or sent anywhere except the PIN check.
/override <block id|last> <reason>	override ONE blocked action (PIN, recorded and witnessed) When a policy block refuses an action (safety level, budget cap, AOCL or WARD deny), a person with a fresh PIN can override that one action. The reason, your name and the block are recorded and witnessed. Today only safety blocks (E-STOP, DEFCON RED dispatch refusals) are honoured by a gate; other block types are recorded but stay blocked, and the answer says so. "last" is the most recent block this window saw.

Skills

Command	What it does
/skills [name]	list your org's governed skills, or show one as a card Lists your org skills (reusable procedures an agent follows; not Crystals, which are deterministic replays) with edition and one-line description. /skills <name> shows its card: purpose, version and review state, tests (results only when run-tests recorded them), the agents it is for, where it came from, recorded use, and how to run it.
/skill <name> [args]	ask Quox to run a skill (governed: approvals still apply) Sends "Run the skill <name> with: <args>" as a normal turn, so CommanderQ runs it through the usual governed path. Nothing is executed from here, and approval cards work as always.
/rules [files|off|on|N]	which rules win: advisory QUOX.md, the dev pack, enforced server policy /rules shows the precedence: QUOX.md and the dev pack only guide; armed governance policies on the server are enforced and win. /rules files shows the QUOX.md text. QUOX.md in this directory and parents up to the git root, plus ~/.quox/QUOX.md, are sent with each turn as your rules. World-writable files and symlinks leaving your home or repo are ignored. /rules N shows page N.
/workflow <name|id|run>	the step flow of a workflow's latest run (or one run): state, timings, human gates Steps come from the workflow definition and each state and duration from that run's recorded envelopes. A reached human gate shows amber. Enter on a workflow row in the roster shows the same flow.
/crystal <workflow>	is this workflow eligible to become a Crystal? checked against the real gate Computed from the workflow's recorded runs with quoxflow's crystalliser rule: at least 3 runs, at least 80% successful, one action sequence. Says how many more successful runs are needed. Related: /crystallize turns what you just did in this conversation into a new skill.
/wish <description>	describe something Quox cannot do yet; Quox drafts a governed spec, you decide (one card, y/n) Quox drafts a short spec through a normal turn: what it does, which existing tools or APIs it would use, the hat and permissions, what tests prove it, and which shape fits (skill, workflow, power or code). On y, a skill is created through skill_manage (experimental, queued for human review) and a workflow through the workflow tool, inactive; a power or anything that needs code is filed as a feature request with the spec. Nothing installs code: that goes through the normal build and review path.
/crystallize [what]	turn what was just accomplished into a permanent reusable skill (rules, tools, tests) One model call drafts a skill from the conversation: rules, the tools used, and tests. The server skill firewall checks it first, then one preview card; y saves it to your skills and prints /skills <name>. Related: /crystal checks whether an existing workflow is eligible to become a Crystal; /crystallize writes a new skill from this conversation.
/automate [task]	turn this conversation (or a task you name) into a persistent workflow One model call drafts a workflow from the conversation: trigger, schedule, steps, approval gates and failure handling. You get one preview card; y creates it in the workflow store and activates its trigger, then prints the id and /workflow <id>. Nothing is created before y.

Conversation

Command	What it does
/clear also /new, /reset	fresh conversation and a clear screen; rules and memory kept, /resume goes back Clears the screen and starts a new conversation. Your QUOX.md rules, attached agent, model choice and Quox memory stay as they are. The previous conversation is kept on the server: /resume lists it.
/resume [id|name]	pick a recent conversation and carry on where it left off Alone: a picker of your recent conversations (title, agent, age); Up/Down and Enter resume, Esc cancels. With an id (or the start of one) or a /rename name it resumes directly. The last turns are shown as history and your next message continues that conversation. Also at launch: quox --resume [id|name] or quox --conversation <id>.
/compact [show]	summarise the conversation on the server, keeping decisions The server summarises this conversation with your AI provider, keeping decisions, and the summary becomes the start of the conversation for later turns. Shows the token change and the first lines of the summary; /compact show prints all of it. Refused while a turn runs, and when the org has not given AI processing consent. Asking "compact this conversation" in words only suggests it.
/challenge [focus]	an adversarial review of the last answer by a different provider (costs one extra model turn) Brutaloop on demand. Sends the last answer and that turn's tool calls and receipts to ONE review turn on a different connected provider (else a different model on the same provider; it says which). The reviewer lists factual errors, unsupported claims, missed failures and unsafe actions, each with a severity and the evidence it rests on, and does not rewrite anything. Read-only, but it costs one extra model turn. Afterwards "Resolve these? y/N": y sends the findings back to the agent that answered, as a normal turn, to fix or rebut each one. The optional focus narrows the review, e.g. /challenge security.
/spawn <cores>c <ram>G <disk>G <lifespan> for <objective> | list | done <vmid>	ask HYPERION for a disposable VM (posts to slot provisioner; lifespan required, max 24h) Order is loose and plain words work: /spawn 4 cores 8G 20G for 2h to test the installer. Lifespan is required (max 24h); at most 3 live VMs per session. You see one card (resources, lifespan, objective, and that it posts to HYPERION); y posts the request to slot provisioner signed by this session, waits for HYPERION's lease reply and prints the vmid, IP, user and how to connect. The lease is stored locally with its expiry and released with "done <vmid>" at expiry, or on /spawn done <vmid>. There is no server-side slot reminder, so expiry runs in this window: if it is closed, the VM is released on the next start, and /spawn list shows overdue leases in red.
/consent [grant [provider]]	AI data sharing consent: see where you stand, or give your OK and carry on Cloud AI providers (OpenAI and other hosted ones) receive your messages and tool results, so Quox needs your OK first; it is personal, not an admin setting. /consent shows where you stand. /consent grant [provider] records your OK (the same as quox consent grant --provider <name>, or Settings > Privacy in the dashboard) and, if a message just failed for lack of it, sends that message again. A local model (Ollama) never needs it.
/help [command]	this reference, or detail for one command or key Type / to open the command list. After a command and a space, the next word is suggested too (providers, live model ids, orgs, agents, slots, options): Up and Down choose, Tab completes, Esc closes, and keep typing to narrow. Suggestions that cannot be fetched are simply left out.
/copy [N|code]	copy the last answer (raw markdown) to the clipboard; N = Nth-last, code = last code block Uses the OSC 52 terminal escape (works over SSH in most terminals; wrapped for tmux). Needs a terminal that allows OSC 52. Mouse selection is untouched: select and copy with your terminal as usual.
/dragon [explain|ask [question]|sleep|fly|hero|fire|classic]	the Q comes alive; /dragon explain gives the simplest possible explanation of the last output, /dragon ask [question] answers one question just as simply, /dragon sleep is a katakana screensaver (any key wakes) Plain /dragon plays the dragon (googly eyes, a talking smile, tail sway and whip, then fire from its mouth); classic and hero are the same show, /dragon fire is the breath alone. explain and ask are ordinary turns on whichever AI you have selected (tools and approvals still apply); the answer stays in the conversation as "Dragon explains" or "Dragon answers". With no AI connected you get the usual connect card. /dragon ask with no question waits for your next line. /dragon sleep hides the screen under katakana with the dragon asleep; any key wakes it and is not typed, an approval wakes it, Ctrl+C quits. It only changes what is drawn, never the conversation. Quiet motion or NO_COLOR shows a still screen.
/dragon-fly	the dragon flies across the screen, wings beating (same as /dragon fly) One 9 second pass of the dragon in flight, wings beating; Esc stops it early. It only changes what is drawn, never the conversation. Quiet motion or NO_COLOR shows a single still frame instead.
/sound [profile|test]	earcons for approvals, failures and long turns: Silent | Minimal | Operational | Full Same setting as the dashboard (your account's soundProfile). Minimal (default) sounds for approvals, critical alerts and failures; Operational adds a short tick when a turn over 20 s finishes or the terminal is in the background. Over SSH only the terminal bell rings, for approvals and critical alerts. QUOX_SOUND=off mutes this terminal; --print never makes sound.
/mouse [on|off]	clicks: a ◆ sender to reply, a card's y / n / c to answer, select text in your draft (off by default) Saved for this profile. On: click a ◆ sender line to start /say to that slot, click y approve, n deny or c chat on a card (or y/N/c on an ask) to answer exactly as the key would, and click, drag or double-click in your draft to place the cursor or select (Backspace deletes, typing replaces). A click never runs a command: a run request still needs y or typing run. While it is on the terminal sends clicks and the wheel to Quox, so hold Shift (Option on macOS) to select or copy text, and Shift+wheel or the scrollbar to scroll back.
/tip	a "did you know" tip about something Quox can do on this install Shows one tip at a time and rotates through all of them before repeating. Only features that are shipped (stable or beta) and ready on this server are offered, and things you already use are skipped. One tip also shows under the greeting on launch. /tip-settings off stops them.
/tips [topic or words]	search the tips: /tips social media, /tips integrations; alone lists the topics Bare /tips lists the topics with how many tips each has. /tips <words> ranks tips by topic, title, text and command and shows up to 5; add "more" at the end for the rest. It respects /tip-settings: tips your setting hides are counted, not shown. /tip still gives one random tip.
/tip-settings [off|core|all]	tips: off = none, core = free features only, all = everything shipped (default); saved on this profile Alone shows the current setting. Saved to your CLI profile, so it survives restarts. core limits tips to the free tier; all includes plugin features your install can use.
/whatsnew [all|on|off]	new commands since you last looked, plus release notes; on/off controls the startup card Quox shows a short "What's new" box once when you start a newer version than last time. /whatsnew lists the latest 10 entries with a command to try; /whatsnew all lists every entry.
/welcome	Show the welcome screen again
/about	who we are, terms, privacy, licence and docs links
/quit also /exit	leave; finished work is kept and /resume picks the conversation up Idle: leaves at once; the conversation stays on the server for /resume (or quox --resume). During a turn it asks first, because leaving disconnects the turn and the server stops it before its next step (a tool already running finishes and is recorded). /quit again within 5 s leaves anyway.
/restart [auto [on|off]]	restart into the latest installed quox and resume this conversation Re-runs the quox on your PATH in this terminal with the same arguments and profile, plus --resume for this conversation. During a turn it asks first: restarting disconnects the turn and the server stops it before its next step (this server cannot reattach a running turn yet); /restart again within 5 s goes ahead. When a newer build is installed than the one running, a dim line says so (checked at most once a minute, no network). /restart auto on restarts for you when that happens and you are idle (5 s countdown, any key cancels); bare /restart auto toggles. Saved per profile, off by default.
/update	update quox to the latest version, then restart Checks how this quox was installed (npm, a git checkout, or this box's shared CLI tree) and the latest version, then shows what is new and asks y/N/c. y hands the terminal to the update (so npm prompts or sudo work), shows its exit status and, on success, restarts into this conversation like /restart (attach and slot carry over). A failed update keeps you in this conversation and says the command to run yourself. A git checkout updates only when clean and on main (git pull --ff-only, never stash or reset); this box's shared tree runs quox-cli-refresh, which updates quox for every session here. A self-hosted install updates with quox server update. Same as quox update in a shell.
/demo	play the simulated demo journey on its own (same as quox --demo --autoplay); nothing real runs Hands the terminal to the autoplay demo: a scripted journey with a simulated server, no input needed, nothing real runs and nothing is sent. Quit it to come back to your normal client; this conversation stays on the server for /resume. During a turn it asks first, like /restart.
/feedback <text>	tell the Quox team something: sent to the quox.ai feedback API after you see it and say y /feedback <text> shows exactly what will be sent (type feedback, your text, and the quox CLI version; no name, email, org or token) to https://api.quox.ai/api/feedback, the Quox team rather than your own Quox server, and asks y/N. y sends it; anything else leaves it unsent. The Quox site takes 5 a hour per address. /gripe is different: it files a GitHub issue through your org.
/gripe <text> also /gripe!	file a GitHub issue through the GRIPE agent; shows it first, /gripe! files at once The same governed path as `quox gripe`: the GRIPE agent files the issue through your org's GitHub connector (default repo quoxai/quox). /gripe <text> shows what would be filed and asks; /gripe! (alone, within 2 minutes) files it, or /gripe! <text> files straight away. The issue link is shown when one comes back; with no link it says so and treats it as not filed.
/sessions [all|refs]	everything live in your org by name and where it runs; refs adds ids, all adds every chat Each row leads with the session name and where it runs (host, or "host unknown" when the server does not know), then how long it has been up and when it was last active. Sections: terminal sessions, slots, work (objectives, loops, workflows) and chats. /sessions refs adds ids and attach commands under each row; /sessions all includes every chat from the last 24 h. The same data as `quox sessions`. Names set with /rename are kept on this machine (~/.config/quox/sessions.json).
/active [sessions|slots|agents]	who is doing what: one line per active worker, grouped working / waiting on you / idle (same as `quox active`) One short summary over the live session index: each line is a name, what it is doing (its state reason, slot or agent, never invented), its state (working, waiting on you, idle Nm, asleep) and since when. Top 10 per group; /active all shows every one. /active sessions, /active slots and /active agents show one kind. A source the server could not read is named in one line. The same data as `quox active`.
/dashboard [page]	open the web dashboard already signed in (one-time link); pages: sessions approvals agents lucid inbox seo settings Creates a sign-in link for this profile that is valid for 10 minutes and works once, then opens it in your default browser. Over SSH it only prints the link (the browser would open on the wrong machine); terminals that support hyperlinks make it clickable. The link is a credential: it is shown on screen only and never written to the dev transcript or history. An older server without one-time links gets the plain dashboard URL and you sign in as usual. Also: quox dashboard [page].
/rename [name]	name this session (shown in the top rule); alone shows the current name Also settable at launch with quox -n <name>. The name is kept on this machine, keyed by conversation, and shown in /sessions.
/slot <name>	give this session a slot address (checks out the slot) Checks out the slot, creating it if needed, as `quox slot checkout <name> --create --session <session>` does; typing it is your consent. While you hold it, every message to the slot (other windows, Discord, Matrix) shows here live, above the composer. /slot log [n] shows the last n messages. A start in the same folder offers to reattach the slot you last held. /config sets a bell for incoming lines.
/say <slot>[,<slot>...] <text> also /ask	message one or more slots directly (no model turn); a,b,c sends each a copy naming everyone it went to Posts straight into the slot, signed as this window (your slot and name), and prints the line with ✔ once it is in the slot. Starting a line with @<slot> does the same.
/join <slot>	join a slot as a group room (read and post without holding it) Subscribes this window to the slot's live stream; the last ~10 messages show first. Holding (/slot) stays separate and exclusive. Post with #<slot> <text> or /say; #<slot> alone makes it the default target (a bare # undoes it). /<slot> join, /<slot> leave and /join #<slot> work too. Your lines are signed with this session's name and person, never as a human profile.
/leave <slot>	leave a slot room you joined (does not release a hold)
/rooms also /groups	rooms (groups) this window has joined, with unread counts; also on the status line
/broadcast [--slots a,b] [--priority urgent] [--ack] <text> also /roar	tell every held slot in this org at once, signed as you One server call delivers to every slot held in this org (never another org), or only --slots a,b. --priority urgent marks it red for recipients. --ack asks them to reply /ack <id>; you then see "Broadcast delivery: delivered N / acknowledged M / awaiting K" update. You get a framed card: how many sessions have it (stored in the slot, listening sessions see it at once) and a separate chat-rooms count (sent / sending / failed). /broadcast status <id> redraws it. Typing it is your consent. Not yet: --at (schedule), --fleet, --org, --voice.
/page <slot> <text>	urgent message to one slot, acknowledgement requested Like /broadcast to a single slot with --priority urgent --ack: it shows red there, asks them to /ack, and you see when they have.
/ack <broadcast id>	acknowledge a broadcast, as the slot this window holds The id is in the broadcast line ("ack with /ack bc_...").
/send <slot> <file>	send a local text file into a slot (64 KB cap) Text files up to 64 KB go inline; the receiving window shows the name and the first lines, /slot log shows the rest. Secret-shaped values (keys, tokens, passwords) are found first: you are asked y/N, and a yes sends them redacted. Binary and larger files are refused (slots have no attachment store yet). Tab completes the path.
/attach [agent] also /summon	send your turns to a specific agent; alone shows the current one The agent name is checked against your org's agent list. Later turns go to that agent (the chat stream assistant field) until /detach.
/detach	back to CommanderQ
/peek <id>	look up an envelope, inbox item, objective, run, WARD receipt or agent by id Works out what the id is from its shape and asks only the read endpoints that fit: a ULID is tried as an envelope, inbox item, objective and workflow run at once; a UUID as a WARD receipt; a name as an agent. Shows a compact card and the quox command for the full record. Nothing found says what was tried and what each answered. Read only, in this window's org. Also: quox peek <id>.
/aside <question>	a read-only side question: no tools, not added to this conversation Asks the model with no tools at all and no conversation id, so it cannot change anything and the answer never enters this conversation's history: your next message carries on as if the aside never happened. The last few exchanges go along as read-only context, so you can ask about what was just said. The answer shows in its own violet block marked read only. Also: quox aside "<question>" (no context).
/r <text> also /reply	reply to whoever last messaged you (slot or room); also /reply
/poke <slot or session> [text] also /wake, /nudge, /ping, /slap, /awaken	wake a session: an urgent page asking it to acknowledge (also /wake, /nudge, /ping)
/huh [question]	the dragon explains what just happened (same as /dragon explain)
/sleep	mark yourself sleeping (sessions stop waiting on approvals, which still queue) and the dragon curls up (/dragon sleep)
/slots [all]	held slots: who holds them and where; free ones are summarised, /slots all lists them (same as /slot list)

Connect

Command	What it does
/login	sign in again without leaving quox (email, masked password, MFA code if asked) Opens a card here: your email (prefilled with the last one this profile used), then a masked password, then your authenticator code if the server asks for one. It is the same sign-in as quox login, so status, approvals and the digest come back without a restart. The password is never echoed, logged or saved. CLI sign-ins last 30 days by default; an org session policy can set a shorter limit.
/profile [name]	switch profile or org without leaving: a chooser of your profiles and this login's orgs, for this window only /profile alone names this window's profile and opens a chooser: the signed-in profiles (this window's marked *), profiles on this machine that are not signed in, then this login's orgs. Up/Down and Enter switch; an org asks y/N first, like /org. Every switch is for this window only: the shared default profile and org in your quox config stay as they were, so other windows and scripts are untouched. /profile <name> also switches straight away. /profile <name> switches this window to that profile in place (or restarts into it carrying the conversation, attach, slot and org). /login <name> does the same when that profile is already signed in. A profile that is not signed in gets a run card for quox login -p <name>. An agent-login window that hits approvals or a step-up offers the switch as a y/N card; it never switches on its own.
/connect [provider]	see what is connected; /connect openai adds a key safely Alone: AI providers (OpenAI, Claude API, Ollama) and the integrations in your org vault, with real status from the server; anything it cannot read shows ? unknown. /connect openai (or anthropic) opens a secure card: paste the key, Enter tests it with the provider and saves it to your org vault as the default; Esc cancels. Keys typed there never reach chat, history or transcripts. A key pasted into the composer is never sent.
/hosts add	add a host to your fleet (works without an AI); /hosts lists them /hosts add prints the one command to run on the machine you want to add (the QuoxAgent installer served by your Quox, with a --host-id of your choice). /hosts lists the hosts your Quox knows, the same as quox fleet hosts. Neither needs an AI connected.
/capabilities [name]	what this Quox can do here: ready, needs setup, not available, planned Asks the server (GET /api/v1/capabilities), which checks real service health, your plan, plugin install state and connected providers. Each gap says why and how to set it up; /capabilities <name> gives the one-line offer for one. If the server cannot answer, nothing is assumed.

Verbose

Command	What it does
/verbose off|on|full	protocol lines (AEE envelopes, VOLT tool offers, WARD): off (default) hides them, on = compact, full = adds thinking; saved off (default) keeps the screen to your conversation, the tool result lines and ONE AOCL footer per turn (layers, tool count, time). on shows the compact AEE / VOLT / AOCL / WARD protocol lines as they happen. full adds the thinking stream. Saved to your profile. The full list of tools offered to the model for the last turn is in /aocl.
/proof [envelope]	the evidence chain for the last tool call: AEE, AOCL, tool, WARD Each link is read back from the server and drawn confirmed only when the read says so. WARD is the server-verified inclusion receipt; it can be slow on a large chain and is bounded, so a link may stay open.
/prove	independently check that the last turn's tool calls really did what they said: receipt chain plus a read-back of the effect For each tool call of the last turn: the receipt chain is re-read from the server (as in /proof), and where the tool is a write we know how to read back (today: slot_create, memory_save) the effect is read from the system of record. ✔ proven = the chain agrees and the effect is there (or it was a read and the chain agrees). ⚠ unproven = it cannot be shown from here (no read mapping for that write, a read failed, no receipt). ✖ contradicts = the call failed, the server recorded a failure, or the effect is not there. Nothing is assumed: an unmapped write is never called proven. /proof is unchanged and shows one call's chain.
/replay [run or conversation id] [page]	rebuild an earlier run from the audit trail: decisions, tools with args, outputs and receipts, in order, paged Alone: the last turn of this conversation (your question, each tool with its args summary, output and receipt id, then the answer). With a conversation id: its saved messages (the server does not link tool envelopes to a conversation). With an envelope or correlation id: that run's tool calls and guard decisions straight from the AEE audit trail. Six steps a page; add a page number for the next. Read-only: it reconstructs what was recorded and never re-executes anything, and sandbox re-execution is not available.
/aocl	every AOCL layer of the last turn: outcome, time, reason Each turn shows ONE AOCL line (layers accounted, passed, bypassed, time; red with the layer name on a reject). /aocl expands the last turn into all 11 layers, L0 ingress to L10 audit, as the server reported them.
/reconcile	check tool calls that ended with effect unknown against the server's record

Context

Command	What it does
/which [profile|org|agent|hat|model|slot|conversation]	what this window is using right now: login, org, agent, hat, model, slot, conversation Alone prints one block; with a word prints just that line. Reads what this window already holds (the hat shows after your first turn), no model call.
/hat [name|new|edit <hat>|delete <hat>]	list the hats, change hat for this conversation, or make, edit and delete hats of your own /hat lists the org hats with the one this conversation wears marked. /hat <name> takes the key or the name you see (/hat DevOps, /hat the devops hat, or a unique start of it) and switches this conversation now: you typed it, so there is no approval card. A privileged hat asks y/N first (or /hat yes). The switch is recorded on the server (quoxhat.binding.selected) and your next message runs on the new hat. Same as approving an agent's hat proposal, without asking a model. Custom hats: /hat new walks you through a hat of your own (name, a starting hat, the agents it keeps and adds); a custom hat offers a turn only its own tools and agents. /hat edit <hat> keeps or drops agents, adds some, and can rename it; /hat delete <hat> removes it and sends conversations wearing it back to the default hat. Built-in hats are not edited or deleted here. Esc cancels a walk and nothing is sent.
/org [switch <name|id> | back]	list your orgs (current marked), switch this session to another one, or go back to the last one /org lists the orgs your login belongs to. /org switch <name or id> matches loosely, asks y/N (or /org yes), then re-scopes the login (the same exchange as quox org switch) and starts a new conversation in that org; the status line shows the org. /org back (or /org -) returns to the org you were in before, with the same single y/N. A switch only succeeds for orgs you are a member of; the server decides.
/afk [note]	tell sessions you are away (they stop waiting on approvals, which still queue); /back then shows everything since, grouped Sets your presence on the server (per user and org): sessions saying into hitl, triage-q or this window's slot see "owner away since 15:54 UTC (note): approvals will queue"; `quox presence`, `quox slot list`, quox ask and agents see it too. Nothing is approved while you are away. /back or any typed message marks you present.
/back	mark yourself present and show what happened since /afk (same as /away)
/mode [ask|plan]	this window's mode: ask first (default) or plan only Alone it shows the current mode and the options. /mode plan: Quox investigates with read tools and proposes the steps and the exact commands, and runs nothing that changes state; the server enforces it, and the answer ends with "Run this plan now? y/N/c" (y switches back to ask and sends the go-ahead). /mode ask goes back. For this window only: kept across /restart, never saved to your profile. Auto mode is not available yet: it needs standing grants (planned).
/mirror [agents]	the Mirror: what CommanderQ sees about this org right now Read-only, no model call. The org-scoped Mirror the server builds from each service and injects into CommanderQ on every turn: identity, health, implants, capabilities, plugins, memory, codebase, and every value it could not read with the reason. /mirror agents lists the agents. For the QuoxMind implants alone use /mind.
/health also /core	Core dashboard summary: services, computers, agents, approvals, missions, failures, licence (also /core) Read-only, no model call. The same server reads the Core dashboard overview uses: service health (GET /api/v1/health/aggregate), computers and agents (as /fleet), approvals and inbox (inbox stats), running objectives and loops, failed workflow runs in the last 24h, and the licence. A section that could not be read says "unavailable" and why, never zero. /status is the session panel; /collector-health still shows it.
/status also /collector-health	profile, org, server and its health, model, agent, slot, session, version The provider and model shown are what the server last reported running (turn.started), not what was asked for. Server health is checked live. Asking "what is my status" in words prints the same panel as a tip.
/cost also /usage	tokens and cost per model for this session, from real usage Counts only what the server reported on turn.finished (input, output and cache tokens, cost when the provider gives one). Cost stays blank when the server did not report it, and says so; nothing is estimated. Asking "what is this costing" prints the same panel.
/context [off|on]	model, tokens, rules, skills, memory, agent, and what the terminal block sent last turn Every message carries a small block (2 KB max, secrets masked) saying what this screen shows: your org, slot and model, the roster rows with their ids, waiting approvals, the last commands and their outcome, and the slash command names. /context shows what was sent last turn; /context off stops it for this session, /context on resumes. It goes to the same provider under the same AI-sharing consent as the chat itself. Conversation tokens are the sum the server reported for this conversation in this session. Skills and memory are real calls to your server; anything it cannot answer shows ? with the reason. Asking "how much context have we used" prints the same panel.
/doctor	the quox doctor checks plus chat checks, as rows Runs the same checks as `quox doctor` (services, auth token, CLI version) in this process, then chat checks: the chat routes answer, a provider is connected, the capability contract.
/server	your self-hosted install: version, health per service, disk, ports, last update The same read-only panel as `quox server status`, for the install Getting started recorded (or the one the running containers belong to). Changing the server is a terminal verb, never a chat action: quox server update (backup first, rolls back on failure), quox server rollback, quox server uninstall, quox server doctor, quox server diag. Each takes --dry-run to show the plan first.
/config also /settings	settings: theme, motion, verbose, model; saved on this profile An interactive card: Up/Down pick a setting, Left/Right or Space change it (saved at once to this CLI profile), Enter on Model opens /model, Esc closes. Theme replaces the env-only QUOX_THEME; if QUOX_THEME is set in your shell it still wins and the card says so.
/model [provider [model] [compact|full]|auto|<n>|fav|default|list]	choose the provider/model for your next turns: a chooser, numbered favourites, a saved default Alone: opens a chooser (arrow keys, Enter selects for this session). Favourites are listed first, numbered, then the live models of each CONNECTED provider (listed by the provider, never from a fixed list). In the chooser f toggles a favourite, d makes the highlighted model your default, Esc closes; current and default are marked. /model list prints what is connected with real status from your org vault (the same source as /connect). /model openai, /model openai gpt-5.4-mini, /model anthropic, /model auto (server policy) pick directly. Favourites: /model fav lists them, /model fav add <provider> <model>, /model fav rm <n|model>, /model <n> or /model fav <n> switch at once. Default: /model default shows it, /model default <provider> <model> sets it, /model default clear removes it; new sessions start on it when its provider is connected (otherwise you are told once and the usual rules apply). A model id missing from the live list is kept with a warning, because new models appear before lists update. Favourites and the default are saved to your account on the server (your user preferences), so they follow you across machines; this profile keeps a copy for offline use. Same for every provider. The choice is sent with each turn; the server decides, and the status line shows what it actually ran. A provider that is not connected is refused with a /connect offer. quox --provider openai does the same for one run. A trailing compact or full picks the prompt profile: compact is a short system prompt for small or local models (the default on Ollama, LM Studio and vLLM), full is the default elsewhere; --prompt-profile does the same for one --print run.
/row [new|add|list|edit <id>|rm <id>|test <id>|reload|on|off]	your own live lines above the status bar: stats from a URL, your Quox, a plugin or a command /row new walks you through one row with y/N cards and shows what it will say before saving; /row edit <id> changes one. Without a template a row reads the status-row contract: JSON {"text", "value", "tone", "trend", "link"} or plain text (quox rows contract prints it). quox rows add|edit|remove|test|share|import does the same from a shell; /row reload picks it up at once (open windows re-read every minute). Rows never carry secrets, and a row from a share bundle never runs a command. /row add <id> url <url> "<template>" [every 60s] [label X] [colour ok] puts one line above the status bar, refreshed on a timer. /row add <id> cmd "<shell cmd>" "<template>" does the same from a command. The template fills {{path}} from the JSON (or {{text}} from plain output), plus count(path) and count(path[field=value]); numbers are shown compactly, for example {{count(runs[state=ok])}}/{{count(runs)}} ok. At most 3 rows, one line each. url rows follow your account (fetched from THIS machine, http or https only, no credentials sent unless the URL is your own Quox server). cmd rows stay on this machine and are never synced. A failing row shows a short red "warning" line and retries with backoff; it never blocks typing. /row test <id> shows the raw value; /row off hides and pauses all rows.

Awareness

Command	What it does
/roster [all]	show or hide the live roster under the status line; all includes background work The roster lists what needs you: pending approvals, then work you started (objectives, loops, manual workflows). Scheduled and event-driven workflows are hidden; background failures show once per workflow in the bar below. /roster all shows everything. Refreshed every 15 s from the server. Down on an empty composer focuses it; Enter peeks, s asks to stop (y confirms), Esc returns. A source the server cannot answer shows nothing and is named here.
/undo [last]	reverse the last thing Quox did, if Quox knows how (one card, y/n) Finds the last state-changing tool call of this conversation that has a receipt, reads the receipt back, says what it did and what reversing it means, and on y runs the registered inverse and prints the outcome. Known inverses today: slot_checkout (release the slot), inbox_move (mail undo), notesq_create (delete the note). The target is bound from the call itself or from the server's own record of it, and only when exactly one record fits; otherwise nothing runs and you get the by-hand route. Anything else says plainly that Quox can't reverse it automatically. Ctrl+_ still undoes composer typing.
/agents [list [text] | <name> [tools]] also /agent	pick an agent from the list, or show one's card: role, tools, slot, last action and its WARD witness /agents or /agents list opens a picker (name, role, status); Enter shows that agent's card; /agents list sec narrows it. /agents <name> shows the card, /agents <name> tools lists the tools it may use. /agent is the same command.
/watch <what> [for <condition>] | list | stop <id>	turn a site, repo, server, page, metric or condition into an ongoing observer /watch quox.ai for downtime, /watch gitea health, /watch competitor pricing page https://... Shows one preview card (what, how often, what triggers it, where it notifies); y creates a scheduled agent check (default every 15 min, min 5) that stays quiet until the condition is met and then raises it in your Approvals inbox. /watch list shows your watches, /watch stop <id> ends one.
/fleet [host] also /soar	computers, agents, missions and SubFleets in one block, with health; /fleet <host> shows one Read-only, no model call. Computers merge the QuoxAgent heartbeats with the Bastion host registry (the same reads as quox fleet agents and quox fleet hosts) and count healthy, degraded, unhealthy and offline, naming anything that is not healthy. Agents are your org agents, missions are running or waiting objectives and loops. SubFleets are designed but have no API in this Quox yet, so that row says so. A source that cannot be read is named on the "Can't see" line, never shown as zero. Moving work is not a command: ask in plain words.
/memory <query>	facts Quox remembers, each with where it came from, age, trust and conflicts
/sitrep	the situation now: approvals waiting, what needs you, running work, what Quox cannot see Read from the server, no model call: approvals waiting (your Approvals inbox), what needs you from the LUCID situation (by urgency), work in motion, and the sources LUCID cannot see (silent, failing or not connected). A part the server cannot answer is named on the "Can't see" line, never shown as empty. Does not move your LUCID cursor. /away is the "since you were last here" digest. Asking "give me a sitrep" suggests it.
/away [since]	what happened while you were away, and what Quox cannot see A factual digest from the server since you last used quox on this profile (or since 90m, 3h, 2d, or an ISO time): approvals waiting and resolved, objectives and workflows finished or failed, LUCID alerts, new Qortex decisions, failed turns and agent activity, each with its source and time. Sources that could not be read or went silent are named on a "Can't see" line. Nothing is summarised by a model. At launch, after more than 2 h away, a short card shows the top 5. Asking "what did I miss" suggests it.
/vm <verb> <target> [args]	Proxmox VMs via the HYPERION agent: list, info, doctor, start|stop|reboot|shutdown, snapshot, rehearse, pool Same verbs as quox vm. /vm list [--node n] [--type qemu|lxc]; /vm info <name|vmid>; /vm doctor <name|vmid> (why is it slow or unhealthy: verdict and ranked findings with evidence and a suggested fix, read only); /vm start|stop|reboot|shutdown <name|vmid>; /vm snapshot <name|vmid> [--name s]; /vm rehearse <name|vmid> [--check url:..|unit:..|cmd:..] [--keep-twin] [--no-wait] -- <command> (runs the command on a network-isolated twin and waits for pass/fail, minutes); /vm pool status|lease|done <vmid>|config. Every action goes through the governed tool route, so a held call prints its approval id and quox approvals result <id> to read the outcome; it is never re-submitted. Names match exactly; an ambiguous name lists the candidates.
/hyperion	which VMs HYPERION has out and who holds each one, one line per VM Read-only, no model call. One line per held VM: vmid, name, node, status, who holds it (pool lease or standing-grant lane), purpose and expiry or age. Same data as quox hyperion, which also shows node load, pool counts and the last 5 operations; quox hyperion deck is the live full-screen view. A VM nobody holds is not listed; a part the server cannot read is named, never shown as empty.
/observers also /observer, /lucid	LUCID situation, what changed since you last looked, what Quox records about its own learning Facts only, read from persisted data: the LUCID situation (without moving your cursor), recent changes, lessons taught, and the reflect / learn / insight counters. Nothing is summarised by a model.
/mind [implant]	QuoxMind cognitive implants: status and last activity; /mind <id> for one Read-only, no model call. /mind lists the 14 cognitive implants (sense, repobrain, memory, temporal, focus, value, guard, qortex, insight, executive, predict, reflect, dream, learn) with status and last activity; /mind predict shows one. An implant with nothing recorded says "no activity recorded". Same data as quox mind implants and quox mind implant <id>.

Generated from the quox client registry at 8210595d6 (quoxcli 0.3.1).

A few worth knowing by name:

• /model shows which AI providers are connected and picks the one for your next turns. The server decides, and the status line shows what actually ran.
• /capabilities asks your Quox what it can do here: ready, needs setup, not available, or planned, with how to set up each gap.
• /share attaches the output of your last ! command to your next message (/share 2 picks the one before). Command output is not shared with Quox by default, because it can contain secrets, so this is how you show it what you saw. Up to 16 KB, and it says when it cut something.
• /tips searches the built-in tips: /tips social media or /tips integrations. On its own it lists the topics and how many tips each has. /tip still gives one at random, and from a shell quox tips <words> does the same search.
• /demo plays the simulated demo journey (the same as quox --demo --autoplay). Nothing real runs and nothing is sent. Quit it to come back, and this conversation is still there for /resume.
• /copy puts the last answer (or its last code block) on your clipboard.
• /sound sets the earcons for approvals, failures and long turns. It is the same setting as the dashboard.
• /dragon brings the Q to life for a few seconds, and /dragon fire breathes fire. /dragon-fly sends the dragon flying across your terminal.
• /huh has the dragon explain what just happened, the same as /dragon explain. You can add a question after it.
• /dashboard opens the web dashboard already signed in, through a one-time link that lasts 10 minutes. Over SSH it prints the link instead of opening a browser.

Managing the conversation:

• /clear starts a fresh conversation on a clear screen. Your rules, agent, model choice and memory stay, and the old conversation is kept on the server.
• /resume picks a recent conversation and carries on where it left off. Give it an id or a /rename name to go straight there.
• /compact has the server summarise the conversation, keeping decisions, so later turns start from the summary. /compact show prints the whole summary.
• /restart re-runs the latest installed quox in this terminal and resumes this conversation. During a turn it asks first.
• /gripe <text> files a GitHub issue through the GRIPE agent, the same governed path as quox gripe. It shows what it would file and asks before filing.
• /feedback <text> tells the Quox team something, rather than your own Quox server. It shows exactly what will be sent (your text and the quox CLI version, with no name, email, org or token) and sends it only on y. Anything else leaves it unsent.
• /update updates quox to the latest version, then restarts into this conversation like /restart. It checks how quox was installed (npm or a git checkout), shows what is new and asks y/N/c. A git checkout updates only when it is clean and on main. If the update fails you stay in this conversation and it gives you the command to run yourself. It is the same as quox update in a shell, and a self-hosted server updates separately.
• /welcome shows the welcome screen again.
• /aside <question> asks a read-only side question. The model gets no tools and the answer never enters this conversation, so your next message carries on as if the aside never happened. The last few exchanges go along as context, so you can ask about what was just said. The answer shows in its own block marked read only.
• /mode shows this window’s mode. /mode plan has Quox investigate with read tools and propose the steps and exact commands while changing nothing, enforced by the server, and ends with “Run this plan now? y/N/c”. /mode ask goes back to the default, ask first. The mode is for this window only: it survives /restart but is never saved to your profile.
• /hat lists the org’s hats with the one this conversation wears marked. /hat <name> switches this conversation to that hat straight away (a privileged hat asks y/N first), and the switch is recorded on the server. /hat new walks you through a hat of your own, /hat edit <hat> changes one and /hat delete <hat> removes one. Built-in hats are not edited or deleted here.
• /mouse on lets you click: a ◆ sender line to reply to that slot, y, n or c on a card to answer as the key would, and inside your draft to place the cursor or select. A click never runs a command. It is off by default and saved for this profile. While it is on, hold Shift (Option on macOS) to select or copy text.

Knowing where you stand:

• /sitrep reads the situation from the server, with no model call: approvals waiting, what needs you by urgency, work in motion, and the sources Quox cannot see.
• /away is a factual digest of what happened since you last used Quox on this profile (or since a time you give, like 3h), including what it could not see.
• /server shows your self-hosted install: version, health per service, disk, ports and last update. It only reads; changing the server is a terminal command, never a chat action.
• /status shows your profile, org, server and its health, model, agent and version. The model shown is what the server reported running, not what was asked for.
• /cost counts tokens and cost per model for this session, only from what the server reported. When the server gives no cost, it stays blank and says so.
• /context shows the model, conversation tokens, rules, skills, memory and the attached agent.
• /doctor runs the quox doctor checks plus chat checks, as rows.
• /login signs you in again without leaving quox: your email, a masked password, and your authenticator code if the server asks. It is the same sign-in as quox login, and the password is never echoed, logged or saved.
• /consent shows whether you have given your OK for a cloud AI provider (such as OpenAI) to receive your messages and tool results. /consent grant <provider> records it, and resends a message that failed for lack of it. A local model (Ollama) never needs it.
• /profile names this window’s profile and opens a chooser of your profiles and this login’s orgs. /profile <name> switches straight away. Every switch is for this window only, so other windows and scripts keep the default in your quox config. A profile that is not signed in gets a card to run quox login -p <name>.
• /active shows who is doing what: one line per active session, slot or agent, grouped as working, waiting on you and idle. /active all shows every one, and /active sessions, /active slots or /active agents shows one kind.
• /health is the Core dashboard summary with no model call: services, computers, agents, approvals, running missions, failed workflow runs in the last 24 hours, and the licence. A section it could not read says unavailable and why, never zero. /core is the same command.
• /mirror shows the Mirror, what CommanderQ sees about this org right now: identity, health, implants, capabilities, plugins, memory, codebase, and every value it could not read with the reason. /mirror agents lists the agents.
• /mind lists the QuoxMind cognitive implants with their status and last activity, with no model call. /mind <implant> shows one, such as /mind predict.
• /peek <id> looks up an envelope, inbox item, objective, workflow run, WARD receipt or agent by its id, working out what the id is from its shape. It shows a compact card and the command for the full record. It only reads, in this window’s org.
• /afk tells your sessions you are away, with an optional note. They stop waiting on you, and approvals still queue: nothing is approved while you are away. /back, or any message you type, marks you present again, and /back shows what happened since, the same as /away.
• /sleep marks you sleeping in the same way, and the dragon curls up.
• /org lists the organisations your login belongs to. /org switch <name> moves this session to another one after you confirm with /org yes, and starts a new conversation there.
• /config opens a settings card for theme, motion, verbose and model, saved on this profile.

Tips and hosts:

• /tip shows a “did you know” tip about something Quox can do on this install. It only offers features that are shipped and ready on your server, skips the ones you already use, and rotates through them all before repeating.
• /tip-settings sets which tips you get: off, core (free features only) or all (the default). It is saved on this profile.
• /vm <verb> <target> drives Proxmox VMs through the HYPERION agent, with the same verbs as quox vm: list, info, doctor, start, stop, reboot, shutdown, snapshot, rehearse and pool. Every action goes through the governed tool route, so a held call prints its approval id rather than being sent again.
• /hyperion lists which VMs HYPERION has out and who holds each one, one line per VM, with no model call.
• /hosts add prints the one command to run on a machine you want to add to your fleet. /hosts lists the hosts your Quox knows. Neither needs an AI connected.

Agents, memory and workflows:

• /agents <name> shows an agent’s card: role, tools, slot, and its last action with the WARD witness.
• /memory <query> lists facts Quox remembers, each with where it came from, its age, trust and conflicts.
• /workflow <name> draws the steps of a workflow’s latest run with state, timings and human gates.
• /crystal <workflow> checks whether a workflow can become a Crystal, against the real rule: at least 3 runs, at least 80% successful, one action sequence.

Checking the evidence:

• /proof walks the evidence chain for the last tool call (AEE, AOCL, the tool, WARD), reading each link back from the server. A link only shows as confirmed when the read says so.
• /reconcile checks tool calls that ended with their effect unknown against the server’s record.

Slots and rooms:

• /slots lists the held slots, who holds them and where. Free ones are summarised, and /slots all lists them too.
• /join <slot> joins a slot as a group room, so this window can read and post without holding it. The last few messages show first. /leave <slot> leaves a room you joined; it does not release a hold.
• /rooms lists the rooms this window has joined, with unread counts. /groups is the same command.
• /r <text> replies to whoever last messaged you, in a slot or a room. It is short for /reply.
• /poke <slot or session> wakes a session with an urgent page asking it to acknowledge, with optional text. /wake does the same.

New since platform 4.2.1

These arrived after platform release 4.2.1 and are in the current one (4.2.5).

• /whatsnew lists what changed in Quox lately, the latest 10 entries with a command to try for each. /whatsnew all lists every entry. Quox also shows a short “What’s new” box once, the first time you start a newer version.
• /say <slot> <text> posts a line straight into another window’s slot without asking the model, signed as your window, and prints it with a tick once it has landed. Starting a line with @<slot> does the same.
• /send <slot> <file> sends a local text file, up to 64 KB, into a slot. The other window sees the name and the first lines. Quox looks for keys, tokens and passwords first and asks before sending; a yes sends them redacted. Binary and larger files are refused. Tab completes the path.
• /broadcast <text> tells every slot held in your org at once, signed as you, in one call (never another org). --slots a,b narrows it, --priority urgent marks it red, and --ack asks each to reply, so you see delivered, acknowledged and still waiting update. Typing it is your consent.
• /page <slot> <text> is an urgent message to one slot that asks for an acknowledgement, and shows you when it comes. /ack <id> acknowledges a broadcast as the slot this window holds.
• /spawn 4 cores 8G 20G for 2h to test the installer asks HYPERION for a disposable VM. The order is loose and plain words work, but a lifespan is required (24 hours at most), and you get one card before anything is sent. It prints the VM’s address and how to connect, keeps the lease with its expiry, and gives it back at expiry or on /spawn done <vmid>. /spawn list shows your leases, overdue ones in red. At most 3 live VMs per session.
• /challenge has a different AI provider review the last answer, with its tool calls and receipts: factual errors, unsupported claims, missed failures and unsafe actions, each with a severity and its evidence. It rewrites nothing and costs one extra model turn. Afterwards you can send the findings back to the agent to fix or rebut. /challenge security narrows the review.
• /row puts up to three live lines of your own above the status bar, refreshed on a timer. /row add <id> url <url> "<template>" fills the template from JSON at a URL, and /row add <id> cmd "<command>" "<template>" does the same from a command on this machine. Templates use {{path}}, count(path) and count(path[field=value]). /row list, /row test <id>, /row rm <id>, and /row off or /row on manage them. A failing row shows a short warning and retries; it never blocks typing.
• /which says what this window is using right now: login, org, agent, hat, model, slot and conversation. /which model prints just that line. No model call.
• /fleet shows your computers, agents and running missions in one block with their health, and names anything that is not healthy. /fleet <host> shows one. A source it cannot read is named, never shown as zero. It only reads; to move work, ask in plain words.
• /watch quox.ai for downtime turns a site, repo, server, page or metric into an observer that stays quiet until the condition is met, then raises it in your Approvals inbox. One card first; it checks every 15 minutes by default. /watch list and /watch stop <id> manage them.
• /automate turns this conversation, or a task you name, into a workflow: trigger, schedule, steps, approval gates and failure handling. You see one card, and nothing is created before you say yes.
• /crystallize turns what you just did into a reusable skill with its rules, tools and tests. The skill firewall checks it first, then one card, and yes saves it to your skills.
• /wish <description> is for something Quox cannot do yet. It drafts a short spec (what it does, which tools it would use, its permissions and the tests that prove it), and on yes creates an inactive skill or workflow for review, or files it as a feature request when it needs code. Nothing installs code.
• /prove checks that the last turn’s tool calls really did what they said. It re-reads each receipt chain from the server and, for writes it knows how to read back (today, making a slot and saving a memory), reads the effect from the system of record. Each call is proven, unproven (it cannot be shown from here) or contradicted. Nothing is assumed.
• /replay rebuilds an earlier run from the audit trail, in order: your question, each tool with its arguments, output and receipt, then the answer. Give it a conversation or run id for an older one. It only reads what was recorded and never runs anything again.
• /undo reverses the last thing Quox did, when it knows how: releasing a slot, moving mail back, deleting a note it made. It reads the receipt, says what reversing means, and runs only on yes. Anything else it says plainly it cannot reverse, and gives you the route by hand.

Planned

These are listed under “Coming” in /help and refuse to run until they are built.

Generated from the quox client registry at 8210595d6 (quoxcli 0.3.1).

Generated from the quox client registry at 8210595d6 (quoxcli 0.3.1).

Approvals

When an action needs a human, a card appears in the conversation with the action, its scope and its risk. Press a to approve, d to deny, o to open it in the dashboard.

These single keys act only when your draft is empty, or after you press Tab to focus the card, so a stray a in a sentence cannot approve anything. Keys arm after 300 ms, nothing defaults to approve, and Enter never approves.

You can also approve later with /approvals, then /approve N or /deny N. Pending approvals also come first in the roster.

• /walkthrough takes you through what is waiting one item at a time: what it does, why, Quox’s advice, then your choice. It is the same as /approvals walkthrough.
• /yestoall approves everything waiting, the same as /approve all. Privileged items still ask.
• /answer 3 b answers a decision a session asked you (through quox ask) by picking option b of item 3. Add a note in quotes and the asker gets it. After /approvals 3 you can leave the number off. /approve all never answers a decision for you.
• /authenticate asks for your step-up PIN once and keeps a “human present” window open for 10 minutes, so approvals an agent raised, high-risk ones and /override do not ask again. You set the PIN in the dashboard, not here, and agent logins cannot use it.
• /authorise N approves item N like /approve N, but asks for your PIN first when no human-present window is open. The digits are never shown, saved or sent anywhere except the PIN check. /authorize also works.
• /override <block id> <reason> overrides one action a policy block refused, with a fresh PIN. The override is honoured for safety blocks (E-STOP and DEFCON RED dispatch refusals); other block types are recorded and stay blocked, and the answer says so. Your reason, your name and the block are recorded and witnessed. last picks the most recent block this window saw.

Protocol lines

Quox shows what the platform did, not only what the model said. Tool rows read as one line each: family, verb, result.

Mode	Shows
off	Collapses to the receipt line.
on (default)	Adds compact lines for the envelope (AEE), policy checks (AOCL) and the witness record (WARD) as they happen.
full	Adds the thinking stream.

Set it at start with --verbose, or during a session with /verbose.

Each turn shows one AOCL line: how many layers were accounted for, passed or bypassed, and how long they took. /aocl expands the last turn into all 11 layers, from L0 ingress to L10 audit, with each layer’s outcome, time and reason as the server reported them.

Receipts

Actions Quox takes end with a receipt line, which can show as pending until the witness record lands. The CLI has a verb to check one receipt against the witness chain, quox governance ward verify --envelope <id>. We have not recorded that flow for this site yet.