ps (list),
show (inspect), and kill (cancel), and adds multi-UUID support to
show and cancel so several operations can be acted on in one call.
op is the short alias.
Subcommands
Examples
Help output
The top-levelop command is a dispatcher: by itself it only prints
usage and routes to the three subcommands described below.
op list – dynamic columns
contree op list (alias op ls) accepts the same filter flags as
contree ps (-a, --status STATUS, -K KIND, --since,
--until, -q/--quiet) and shares its rendering pipeline. Reach
for it when you want the operations namespace to feel symmetric with
the multi-UUID show and cancel; otherwise contree ps is just
as good. -S is the global session flag and only works BEFORE the
subcommand.
The listing renders every scalar top-level field the API returns,
not a hard-coded subset. When the server adds a new field (for example
cost, project_id, started_at), it appears in the output without a
CLI release. Nested structures (metadata, result, tags) are
filtered out – use op show UUID for the detail view.
Known fields are lightly typed:
Column order follows the API response, with one exception:
error
is pinned to the last column. Long free-form error messages would
otherwise push the rest of the row out of alignment.
op show – multiple UUIDs
Each UUID is fetched and rendered through the same code path as
contree show, so cached terminal results and history references work
uniformly. Accepted reference forms (mirroring session rollback
syntax with a git-style alias):
@,:, orHEAD– the operation at the active branch tip.@N(or:N, bareN) – absolute history id.@-N,:-N, orHEAD~N– walk N steps back from the tip.HEAD~– shorthand forHEAD~1.@+N(or:+N) – walk N steps forward from the tip, picking the latest child at each branch point.
1 at the end.
With table output (
-o table) and several UUIDs, each operation
currently renders as its own mini-table. Use default or json for a
unified stream view across multiple UUIDs.op wait – block until completion
Poll the given operations until each reaches a terminal status
(SUCCESS, FAILED, CANCELLED) and print one row per completion
with the columns uuid, status, exit_code, timed_out,
duration (and every other scalar field the API returns; error is
pinned to the last column).
--all waits for every currently active operation in the project.
--timeout SECONDS (default 60) caps the wait — when the deadline
hits, the command emits one extra row per unfinished operation with
timed_out=true and the operation’s last observed status (e.g.
EXECUTING), then exits with status 1.
status is the server’s word: it reflects orchestration (did the
API run the job?), not what the sandbox process did with its exit
code. The exit code is a separate column. The CLI’s own exit status
is 1 whenever any operation finished non-SUCCESS, or the actual
exit_code when a SUCCESS op exited non-zero — so
op wait UUID && next-step composes correctly with sandbox commands
like run -- false.
op wait is a pure observer: it polls operation status and
prints rows, but it never updates session state. In particular,
the detached-<op-uuid> branch created when you ran
contree run -d keeps pointing at the starting image — op wait does not advance it to the result image. The pattern therefore
fits non-image-producing runs (--disposable) most cleanly; for
non-disposable fan-out, the result image of each leg lives only on
the server and you must recover it explicitly (see the non-disposable
example below).--disposable fan-out, no image to track. Note the
global -o json before run so jq sees JSON; the default
formatter is plain.
op cancel – multiple UUIDs or --all
Either pass UUIDs explicitly or use --all to cancel every active
operation (PENDING, ASSIGNED, EXECUTING). Combining both is allowed:
--all wins, and the explicit UUIDs are ignored with a WARNING. As
with op show, errors on individual UUIDs do not abort the run; the
command exits 1 if any cancellation failed.
Comparison with the top-level commands
contree ps and contree kill are top-level shortcuts that share
the same argparse setup and handler as op list / op cancel
respectively — there is no separate implementation. contree show
keeps its own single-UUID handler (the multi-UUID op show wraps it).
See also
- ps - List activity – top-level shortcut for
op list - show - Inspect an operation – single-UUID inspect (delegated to by
op show) - kill - Cancel operations – top-level shortcut for
op cancel - run - Execute a command in the sandbox – the command that creates operations