Skip to content

CLI reference

Last updated: 2026-08-16

New to the vocabulary? See the glossary.

I want to…Use
Run something once and throw it awayrun
Run one task and see what it touched on the networkdispatch
Keep a workspace around between bootscreate, then start
Get a shell inside a workspaceconnect
Run a command inside and get its exit codeexec
Copy files in or outcp
See saved workspaceslist or ls
See what’s runningps
Dig into one workspacestatus
Block until a run finisheswait or start --wait
See what the VM printed at bootlogs
Get the structured result of a runresult
Park it / shut it down / force ithalt (alias stop) / kill
Freeze it in place, memory and allpause / resume
Checkpoint or fork itsnapshot, clone
Get rid of itdelete
Figure out why nothing bootsdoctor
CommandPurpose
initScaffold a starter agent project
runBoot an image and run a command, then tear down
dispatchRun one task in a single-use workspace with an egress audit receipt
createCreate a named, persistent workspace
applyApply supported workspace spec changes without rebuilding
cloneCopy a stopped workspace into a new workspace
commitSnapshot a stopped workspace rootfs into an OCI image
resizeGrow or shrink a stopped workspace’s rootfs disk
cpCopy files into or out of stopped workspace disks
artifactList and retrieve declared workspace artifacts
networkInspect declared network intent and runtime network state
modelDownload and manage local HuggingFace GGUF model files
volumeManage named volumes - VM-independent ext4 disks attached by name
startBoot a stopped workspace
superviseStart and restart a workspace according to policy
haltClean disk-preserving shutdown (stop alias)
quarantineFreeze, sever authority, capture, and stop into custody
pauseFreeze a running workspace’s vCPUs, preserving memory and disk
resumeThaw a paused workspace back to running
killHard terminate
deleteRemove a workspace and its state
statusShow workspace state
waitBlock until a workspace’s run finishes
resultShow structured workspace result
listList saved workspaces (ls alias)
psList running workspaces
logsShow boot/serial output
eventsShow or stream the lifecycle event history
egressShow or stream the egress mediator’s audit decisions
statsShow or stream workspace resource usage
snapshotCreate, list, or remove workspace snapshots
secretResolve and validate secret references
connectOpen the workspace console
execRun a structured command in a workspace
profilesList exact named resource profiles
imageManage local image records
registryStore credentials for private OCI registries
perfMeasure workspace boot performance
serveRun the MCP stdio server for agent clients
contractPrint the runtime fields integrations rely on
hostReport host backend capabilities
doctorCheck the host for backend support
rootfsBuild a rootfs from an OCI image
kernelInstall or verify a custom kernel
gcReap dead VM processes and stale workspace state
versionPrint the version

microagent run accepts both the explicit --image IMAGE --exec "cmd" form and the shorter microagent run IMAGE [COMMAND ARG...] form. For flags that map cleanly onto a microVM, common aliases are available: -e for --env, -p for --publish, -v/--volume for named volumes, tar bundles, and ext4 disk images, --name, and --rm.

Some Docker-style inputs do not map to a microVM boundary - privileged mode, namespace flags, devices, and host directory bind mounts. When microagent run recognizes one of these, it returns targeted guidance rather than silently changing its meaning.

microagent.yaml is the declarative form of microagent create - image, profile, restart policy, networking, mounts, mediation, and outputs in a single file you can keep in source control.

These flags may appear before or after the subcommand and apply across commands that produce output. Subcommand pages link back here rather than repeat them.

For run, dispatch, and exec, place them before the image or workspace name so guest flags are never touched. In flag form (run --image IMAGE --exec "cmd" --json), the parser tracks which flags take a value, so a trailing --json is still extracted. In positional form (run IMAGE COMMAND ARGS...), everything after the image is passed to the guest verbatim - a global flag placed there is not extracted.

The CLI has one interaction model for human operators. Output can be rendered as text or serialized as JSON for scripts:

  • --output <json|text> - select output format
  • --json - sugar for --output json
  • --progress <auto|plain|off> - select animated, non-animated, or disabled human progress
  • --no-color - disable the ANSI color some text output uses on state words (failed, running, ready, ok, PASS, WARN, quarantined, paused). Color is a redundant channel only: the word itself is always printed regardless. It is applied only on a TTY, and is also disabled by the NO_COLOR environment variable; JSON output never carries color.

Format is resolved in this order - the first one set wins:

PrecedenceSource
1An explicit --output/--json flag
2MICROAGENT_OUTPUT=json|text
3TTY detection (text on a terminal, json otherwise)

Progress is human presentation, not result data. In the default auto mode, an interactive terminal gets one animated current line with aligned elapsed time and a stable completion line. Redirected text output gets bounded plain phase transitions with no ANSI controls or spinner frames. Progress is written to stderr; command results and streamed guest data remain on stdout.

Use plain for a screen reader, reduced-motion terminal, or stable operator logs. Use off when automation wants text results without progress:

Terminal window
microagent --progress plain start research
MICROAGENT_PROGRESS=off microagent --output text rootfs build --image alpine --out rootfs.ext4

A plain rootfs build uses stable phase lines and one completion line:

• Build rootfs · fetching manifest
• Build rootfs · building ext4 image
✓ [ 1.42s] Build rootfs

The explicit flag takes precedence over MICROAGENT_PROGRESS. Supported values for both are auto, plain, and off. JSON always disables human progress, regardless of this setting. MCP protocol output and its AX responses remain typed and never contain terminal presentation; a person launching the server from a terminal may see only its startup acknowledgement on stderr.

Plain progress is designed to be readable and bounded in logs, but its wording is not a machine API. Agent clients that need intermediate state should consume typed operation events when a command exposes them, rather than parse terminal text.

The removed --mode ux|ax profiles are not accepted. Scripts should use --json; agent clients should use microagent serve mcp. See MIGRATION.md.

--supervisor <path> overrides the installed host backend supervisor path (MICROAGENT_APPLEVF_SUPERVISOR and MICROAGENT_FIRECRACKER_SUPERVISOR work too), but it is not a global flag - pass it after the subcommand, on the commands that accept it.

All commands can print JSON output. With --json before the subcommand (or MICROAGENT_OUTPUT=json), the response uses the same structured result shape the Go library and MCP adapter use. Scripts should consume JSON; humans get the text format by default.

Failures carry the same classification MCP clients receive. In text mode the message is followed by an indented remediation line when one is known. With JSON output explicitly selected, the full structured error — kind, message, remediation, retryable — is written to stderr as one line (stderr, because stdout may already hold the command’s own payload).

Exit codes say what to do next, not just that something happened:

ExitMeaning
0success (including asking for help)
1the operation ran and failed; fix something before retrying
2usage error — the command line itself was wrong
75transient failure (retryable: true); retrying may succeed unchanged

Commands that run guest code (exec, run, dispatch) pass the guest’s own exit code through; the codes above apply to microagent-level failures.