wait-for
Blocks until the workspace's readiness probe (/api/graph/ready) returns true, or until the timeout elapses. Use this in CI/CD scripts to gate the next step on the workspace being live, with no need to poll yourself.
The command does not need a token — it only hits the unauthenticated readiness endpoint.
Usage
# Wait up to 30 minutes (default)
curiosity-cli wait-for --server https://my-workspace.example.com/
# Wait up to 5 minutes
curiosity-cli wait-for --server https://my-workspace.example.com/ --max-timeout 300
# Wait forever (-1 means "up to a week")
curiosity-cli wait-for --server https://my-workspace.example.com/ --max-timeout -1
Options
| Flag | Alias | Default | Description |
|---|---|---|---|
--server |
-s |
- | Workspace URL. |
--ignore-certificate-errors |
-i |
false |
Disable TLS validation. Local/dev only. |
--max-timeout |
1800 |
Maximum wait in seconds. Use -1 for effectively unlimited (capped at 7 days). |
Behavior
The CLI polls every 1–6 seconds (randomized to avoid thundering herds) and logs the current state on every attempt:
info: Application at https://my-workspace.example.com/ is not ready, got connection error: ...
info: Application at https://my-workspace.example.com/ is not ready, got response: false
info: Application at https://my-workspace.example.com/ is ready
The process exits 0 the moment the workspace returns true. If the timeout elapses first, the loop exits without setting an error code — wrap the call in test or your own assertion if you want CI to fail on timeout:
curiosity-cli wait-for -s "$URL" --max-timeout 600
curiosity-cli test -s "$URL" -t "$CURIOSITY_TOKEN" # fails the build if still not ready
See also
test— verify auth once the workspace is ready.- Workspace deployment / Operations — broader CI/CD patterns.