# Commands and background processes

> Enable model command tools, inspect sandbox and approval details, use your own shell command, and track or stop the background processes Code owns.

Source: https://kaitoi.io/docs/cli/commands-and-processes/
Section: Kaitoi CLI / Working with Kaitoi Code
Written for: Developers running checks or local servers with Code.
Prerequisites: A trusted workspace
Last reviewed: 2026-10-24

---

Code has three distinct command surfaces: commands the model proposes, background
processes it manages, and `/cmd` commands you type yourself. Their lifetimes and
permission rules differ. This guide covers CLI **0.9.0**.

## Enable commands for the model

Use Build mode and a trusted workspace, then:

```text
/commands on
/permissions
```

Or start with `kaitoi code --commands --workspace /path/to/project`. Enabling
the tools does not approve the next command. Review the concrete command, working
directory, sandbox status, and requested authority on its approval card.
Saved project command rules or session grants can cover later matching calls.

`/permissions remove <number>` removes a displayed project command rule. `/permissions clear`
clears session approvals; `/permissions clear project` clears saved project
command rules. Use the numbers from the current listing.

## Read the sandbox status

Model commands use the available platform sandbox and its configured access.
An argument-vector command can still be offered without an available sandbox;
the card says it is **not sandboxed**. Shell-string commands, including pipes
and compound shell syntax, require an available sandbox. Do not assume that
“commands enabled” means every machine provides identical isolation.

Foreground command runs are bounded and can time out. Read the exit status and
output: a successful process launch is not a successful test. Large output can
be stored separately with a bounded preview; ask Code to inspect the relevant
output rather than assuming the visible tail contains every error.

## Keep a server running while you work

Ask Code to start a background process when the task requires a persistent
development server or watcher. The tool returns a process ID, such as `proc-1`.
Code can inspect output and wait for readiness; a readiness message or running
PID does not by itself prove the application is healthy.

```text
/processes
/processes stop proc-1
```

Replace the example ID with one in your listing. `/processes stop all` stops
the ordinary background processes managed by this Code invocation. The manager
supports up to six running processes and cleans up its owned processes on exit.
These are not durable Crew runs or arbitrary operating-system processes.


An approved background start creates proc-1. Turning /commands off prevents
future model command tools but leaves that existing process running. The
operator can use /processes stop proc-1 to stop it. A process that exits is
different from one that is running and ready. The illustration follows this
lifecycle and runs no shell command.

*Figure: Disabling future command tools and stopping an existing process are different actions.*

`/commands off` hides future model command tools and stops project-code language
servers. It does **not** stop ordinary background processes already running.
Neither `/clear` nor `/resume` is a substitute for `/processes stop`.

## Run your own command with /cmd

```text
/cmd git diff --stat
```

This is an explicit operator shell passthrough. It runs in the current workspace
(or current directory), with your environment, outside the model tool sandbox
and its approval flow. It is available independently of model command settings
and Plan mode. Only use it for a command you intend to run yourself.

The terminal shows raw output. Code retains a bounded, redacted copy as context
for the next message; that is not a guarantee that the raw terminal output is
safe to share. `/cmd` has its own timeout and is not the managed background
process interface.

## Recover from a stopped or failed command

Inspect the exit result, check whether a background process is still running,
and review any partially changed files. Stop the owned process explicitly if
needed. Undo cannot reverse remote changes or everything a command touched;
use the appropriate service or version-control recovery when necessary.