Wait

cmd/crewship/cmd_wait.go polls a run’s status until it transitions to a final state, then exits with a status-aware code so scripts can act on the outcome without re-parsing JSON. The run id may be an agent run or a routine (pipeline) run — the agent-run endpoint is probed first, and a 404 falls through to the routine-run endpoint, so callers don’t have to know which subsystem produced the id.

`crewship wait <run-id>`

Flag	Type	Default	Effect
`--timeout <dur>`	duration	`30m`	Hard ceiling on the wait. `0` = forever.
`--interval <dur>`	duration	`2s`	Poll cadence. Values ≤ 0 fall back to `2s`.
`-q`, `--quiet`	bool	`false`	Print only the terminal status string (no `[wait]` log lines, no `[done]` banner).
`--routine`	bool	`false`	Treat `<run-id>` as a routine run id and skip the agent-run probe.

A routine run parked on a human approval (status waiting) is not terminal — wait keeps polling until the waitpoint is approved/rejected and the run finishes, or --timeout fires. When neither --quiet nor a structured --format (json/yaml/ndjson) is set, status transitions are logged to stderr as [wait] <run> status=<S> elapsed=<dur> and the final state lands on stdout as [done] <run> status=COMPLETED elapsed=12s.

Exit codes

Code	Meaning
`0`	`COMPLETED` (or a routine `dry_run`)
`1`	`FAILED` (or a routine `interrupted` by a server restart)
`2`	`CANCELLED`
`3`	`TIMEOUT` — server-reported, or `--timeout` reached
`4`	Network/auth error before any status could be read, or the id matched neither run kind

wait is the one documented exception to the CLI’s structured-error contract: because it owns these run-outcome exit codes, error diagnostics are printed to stderr as plain [wait] error: ... text even under a machine --format — there is no JSON/YAML error envelope. Branch on the exit code, not on parsing stderr.

Examples

RUN=$(crewship ask --no-stream -q "do X" | jq -r .id)
crewship wait "$RUN" && echo "done" || echo "broke"

crewship wait r_abc --interval 500ms --timeout 5m
crewship wait r_abc --quiet                       # prints "COMPLETED" or similar
crewship wait r_abc --format json                 # full RunDetail on completion

# Routine runs work too — e.g. the run_id from `crewship routine run`
crewship wait prun_xyz --routine --timeout 10m

Scope: agent + routine runs only

crewship wait (and its --timeout/--interval polling contract) covers agent runs and routine (pipeline) runs. A handful of other long-running commands have grown their own --wait flag that polls a command-specific status endpoint instead of routing through wait:

Command	What `--wait` polls
`crewship run` / `crewship ask`	`--wait` is a spelling alias for `--no-stream` (block on the WebSocket stream itself — no separate poll).
`crewship pipeline run --wait`	`GET /api/v1/workspaces/{id}/pipeline-runs/{id}`
`crewship mission start --wait`	`GET /api/v1/crews/{crewId}/missions/{missionId}`
`crewship hire --wait`	`GET /api/v1/agents/{id}` (waits out a `guided`-crew `PENDING_REVIEW` approval)

crew provision / crew rebuild block by default (pass --no-watch to opt out) via their own devcontainer-build poll, so they don’t need a --wait flag at all.

Getting started

Sessions & identity

Agents & conversations

Crews, projects & workspaces

Missions & routines

Issues & triage

Skills & integrations

Inbox & notifications

Memory & journal

Observability

Cost & paymaster

Approvals & hooks

Configuration & system

Utilities

Wait

Wait

`crewship wait <run-id>`

Exit codes

Examples

Scope: agent + routine runs only

See also

​Wait

​crewship wait <run-id>

​Exit codes

​Examples

​Scope: agent + routine runs only

​See also

Wait

`crewship wait <run-id>`

Exit codes

Examples

Scope: agent + routine runs only

See also