Skip to main content
Mobster tells you why something ended in four places: the exit code of a command, the status of a task, the verdict of a check, and the error code of an HTTP answer. Troubleshooting starts from what you see instead.

Exit codes

Every command uses the same small set. A script can branch on them without reading the output. SIGTERM exits 143 and SIGHUP 129, the same way as ctrl+c.
mobster verify and mobster test exit 3 on a usage error, not 2, because 2 means a check needs review.
mobster test decides from the checks that aren’t quarantined, in this order: 1 when one failed (or was flaky, with --strict), else 3 when one couldn’t run, else 2 when one needs review, else 0. mobster chat adds one: 2 when the task waits for you (an approval or a question), and 4 when it’s still working when --wait runs out. CLI reference gives each command’s codes.

Statuses

A task’s result has a status. mobster run --json prints it in its last line, and the HTTP API and the Mac app’s History show it too. Troubleshooting: tasks has what to do for the ones people meet most.

Verdicts

A check ends with one of four verdicts. The verdict comes from your assertions on the accessibility tree, never from a model.

Reason classes

reason.class in the result says why a check failed, couldn’t run or needs review. Checks has the order these rules apply in, and Troubleshooting: checks what to do about each.

HTTP codes

The local API that mobster serve and the Mac app run answers errors with a status and a short code. The codes you’re most likely to meet: Each area lists its own codes beside its routes: Scripts and the API, Conversations, Memory and Files.