Commands and background processes.

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:

/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.

/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.

/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

/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.