Channel commands

Slash commands are quick instructions you type to control Fermix, handled directly instead of being sent to the agent as a question. Fermix understands a small set of them. They work in every channel you connect (Telegram, WhatsApp, Slack, Discord, Signal) and locally through fermix ask and fermix chat. The ACP surface is the one exception: it runs no command pipeline at all, so a message starting with / reaches the model there as ordinary text. A command is the first word of a message, for example /ultra summarize my open pull requests.

Anything Fermix does not recognize as one of its commands — including an unknown /word — is passed through to the agent as an ordinary message, so a slash at the start of a sentence never errors.

Who can run what

Two commands are open to any authorized sender: /help and /whoami. Everything else is operator-only (the channel owner, or any local CLI caller). command_allowlist opts a guest into part of that set — /new, /clear, /compact, /tasks, /pause, /resume, /ultra, and the /sandbox subcommands. The rest take a stricter gate that never consults the list, so an allowlisted guest is still refused: /grant, /revoke, /confirm, /soul, /skills, /stop, and /background. Each of those either acts across the whole daemon or writes durable state a guest could then approve for themselves. A sender without permission gets a short refusal (“This command requires owner permissions.”) and nothing runs. /help only lists the commands you are allowed to run. See ingress and trust.

Command	Aliases	Who	What it does
/help		anyone	List available commands
/whoami		anyone	Show your stable channel user id
/new	/clear	operator	Start a fresh conversation session
/compact		operator	Summarize and compact the conversation now
/background	/bg	operator	Run a request as durable background work
/tasks		operator	List running and recent background work
/stop		operator	Emergency-stop: cancel active turns, queued messages, background work, and active coding-agent runs
/pause		operator	Hand the cursor and keyboard back during a computer-use session (the session stays alive)
/resume		operator	Continue a paused computer-use session
/ultra		operator	Run a task in exhaustive, wide fan-out mode
/soul		operator	Review and curate the agent persona (SOUL.md)
/skills		operator	Review, approve, or deny skill-curation proposals
/sandbox	/grant, /revoke, /confirm	operator	Inspect or change the workspace sandbox

Conversation

/help and /whoami

/help lists the commands available to you. /whoami prints the stable channel user id Fermix uses to authorize you, which is the value you put in owner_user_id or command_allowlist.

/new (alias /clear)

Starts a fresh conversation session: the current conversation window is cleared. Long-term memory, scheduled jobs, and resource history are untouched.

/compact

Forces conversation compaction now. Older messages are summarized and replaced with the summary plus recent turns, freeing context. Compaction also runs automatically after a turn once usage passes a threshold (default 0.85 of the model context window). See prompt and compaction.

Background work

/background (alias /bg)

/background <prompt> runs the request as durable background work instead of inline, so a long job keeps going while you do other things. Fermix posts the result back to the same chat when it finishes. Use /tasks to check on it and /stop to cancel.

At most 8 background tasks run at once, across every conversation. A /background sent past that is refused outright — “Too many background tasks already running (limit 8). Wait for one to finish, or /stop to cancel them, then try again.” — never queued, and never allowed to displace a task already running. The ceiling is built into the daemon; it is not a config.toml setting.

/tasks

Lists running and recently finished background work for this conversation.

/stop

/stop is the emergency brake. It cancels every active turn, clears all queued messages, and stops background work — across all conversations, not just the chat you send it from. It also stops coding agents: every active coding-agent run on this machine is cancelled, including one a scheduled job started, and a stopped run never continues on its own. It is handled ahead of the queue, so it acts immediately instead of waiting behind the work it is stopping, and its reply reports exactly what was cancelled, including the number of coding runs. Scheduled jobs themselves and realtime voice are not affected.

A stopped turn neither delivers nor commits a reply. Because your message was already saved at the start of the turn, the gateway appends a short marker after it (“stopped before I finished, context only”) so the next turn does not silently replay and answer the abandoned request.

/pause and /resume

/pause is the non-destructive counterpart to /stop. It hands the cursor and keyboard back to you: the computer-use session stays alive and refuses further actions until you /resume — unlike /stop, which tears the session down. It takes effect between the session’s serialized actions, so it lands as soon as the action in flight finishes rather than queueing behind the whole task.

Both are owner-only, and unlike /stop they apply only to the conversation you send them from. /resume lets the session act again but does not pick the task back up on its own — tell Fermix what to do next. With nothing to act on you get a short reply instead: “No active computer-use session to pause.” or “No paused computer-use session to resume.” See computer use.

/ultra

/ultra <prompt> runs a single complex task in exhaustive mode. It is not a separate orchestrator. It tags the normal turn with run_profile: :ultra, which lets the agent spin up many more sub-agents (helper agents that work on pieces of the task in parallel) and adds an exhaustive-mode instruction to the prompt.

What changes in ultra mode:

• Wider fan-out. A normal turn’s subagents tool runs up to 10 tasks (8 concurrent at most, 4 by default). Ultra raises this to roughly 50 narrow probes, up to 12 concurrent, each looking less deeply.
• Breadth and depth. The added instruction drives both many narrow probes (breadth) and several independent sub-agents on the same hard sub-problem, then keeps the best-supported answer (depth).
• Same tracing and limits. Ultra workers are recorded under the parent task like ordinary sub-agents, stay brief by instruction rather than a hard cap, and the safeguard that stops an agent repeating the same tool call still applies.

Ultra’s tuning is system-side configuration (:subagents, :ultra, :iteration_limits), not a config.toml surface. Reach for it on genuinely hard, wide questions where breadth and cross-checking pay off; a normal turn is better for everyday tasks. With no prompt, /ultra prints its usage. See agents and the agent loop.

/soul

/soul curates the agent persona file, SOUL.md. It is owner-only and never runs on its own. Editing the persona is a deliberate, two-step, reviewable process: you draft a change, read the diff, then apply it explicitly.

Command	What it does
/soul	Report the current SOUL.md revision
/soul review [instruction] [--with-context]	Draft an edit and return a diff plus rationale (does not write)
/soul diff TOKEN	Re-preview a pending draft
/soul apply TOKEN	Apply a pending draft (the explicit second step)
/soul history	List persona revisions
/soul revert N	Roll back to revision N (confirmed with /soul apply TOKEN)
/soul reset	Restore the shipped default persona (confirmed with /soul apply TOKEN)

How a review works:

• No instruction drafts a subtle, voice-preserving review held to a small change budget. It declines if nothing warrants a change.
• An instruction (for example /soul review be more concise in status updates) is an explicit, unbounded ask.
• --with-context folds a hard-bounded window of your own recent messages into the draft as evidence. Guest messages are filtered out.

The draft is a single contained model call that has no tools and never writes. It returns a diff and rationale, and surfaces a warning if it detects prompt-injection markers (hidden instructions that try to hijack the agent) in the source memory. Applying needs a second explicit step, /soul apply TOKEN. The token expires after five minutes, long enough to read the diff. Reverts and resets are two-step in the same way: each replies with its own token that you confirm with /soul apply TOKEN. Every write, including reverts and resets, is saved as a numbered revision you can roll back to. See resource versioning.

/skills

/skills drives skill curation: the background pass that reads your own recent messages, spots tasks you repeat, and proposes a skill for them. It only ever proposes — approval is yours, and nothing is written until you give it.

Command	What it does
/skills review	Run a curation pass now (acknowledges immediately, delivers the outcome here when it finishes)
/skills proposals	List pending, denied, and parked proposals
/skills approve TOKEN	Approve a proposal and let Fermix draft and write the skill
/skills deny TOKEN	Deny a proposal and bury the idea
/skills list	List your skills grouped by origin (curation-managed, your own, plugin) with usage counters; bundled skills are excluded
/skills archive NAME	Reversibly archive a curation-made skill
/skills unpark TOKEN	Allow a buried idea to be proposed again
/skills restore [NAME]	Undo an archive or an approved body update

Proposals arrive on their own, in your own private conversation — when there is one to deliver to. With no owner-private inbox configured, the pass still runs and still records proposals but delivers nothing, and they wait until you run /skills proposals. On Telegram and Discord a delivered proposal carries one-tap Approve and Deny buttons that send the identical typed command, so the button and the text are one code path rather than two. /skills review, /skills proposals, and /skills list print your own mined history, so they run only in a direct chat or the CLI; a group chat gets a redirect instead of the content. With curation switched off in config, a pending proposal can still be denied but not approved.

/sandbox (aliases /grant, /revoke, /confirm)

Inspect and adjust the workspace sandbox (the restricted area, with limits on which files, commands, and environment the agent can use) that file, shell, and git tools run inside.

Command	What it does
/sandbox status	Show the current mode and grants
/sandbox explain	Explain the active policy
/sandbox mode MODE	Set the mode (strict, standard, or open)
/sandbox env allow NAME	Allow an environment variable through to tools
/sandbox env set NAME -- COMMAND ARGS	Set an env var from a command’s output
/sandbox env deny NAME or /sandbox env unset NAME	Remove an env var
/sandbox commands profile PROFILE	Switch the command profile (bare, assistant, or extended)
/sandbox commands enable NAME	Enable an extra command preset
/sandbox commands disable NAME	Disable a command preset
/grant path PATH	Grant filesystem access to a path
/revoke path PATH	Revoke a path grant
/confirm TOKEN	Confirm a pending sandbox action

Changes that loosen the sandbox (a more permissive mode, a new path grant, a new environment variable, an enabled preset) are two-step: Fermix replies with a diff of the proposed change and a token, and you confirm with /confirm TOKEN within 60 seconds, from the same chat and sender that proposed it. Changes that only tighten the sandbox (revokes, denies, disables) apply immediately.

The agent can also ask for access itself. When a task needs a directory outside the sandbox, the agent requests it (the request_directory_access tool) and you receive the same kind of prompt — the exact path, the agent’s stated reason, and the config diff — with a /confirm TOKEN. The token is single-use, expires after 60 seconds, and only works from the chat where the prompt appeared. On Telegram and Discord the prompt also carries a one-tap Approve button; it sends the identical confirmation and rides the same single-use, time-limited, origin-bound, owner-only path. Every other surface shows the same prompt as text. In a shared chat on a button channel the code itself is deliberately withheld — approve from the button, a direct message, or the CLI. Changes you propose yourself, above, get no button and always take the typed /confirm TOKEN. Confirming saves the grant like /grant path would and, in a chat channel, automatically resumes the request that needed the access; declining is as simple as ignoring the prompt. Only you get these prompts, and only in a live conversation: guests, scheduled jobs, and unattended runs never see an approval path. Unsafe roots (your whole home directory, Fermix’s own data directory, credential directories like ~/.ssh) are refused outright — the agent cannot even ask for them.

See sandbox and permissions for the full model.