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 astatus. 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 thatmobster 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.