Headless Runs
Start Mogplex work from scripts, CI, dashboards, or automation without opening the interactive CLI.
Headless runs are for non-interactive execution.
Use this surface when another system should start Mogplex work, tail the event stream, and make a decision from the final status.
Good fits
- GitHub Actions or another CI system starts a fix or investigation run
- an internal dashboard launches a repo task
- a scheduled script starts maintenance work
- a tool starts a run and streams events into its own logs
- an operator wants repeatable JSON output instead of the TUI
If a human should actively supervise tool approvals, diffs, or model changes, use the interactive CLI instead.
Core lifecycle
The headless path mirrors the hosted run lifecycle:
- start a run with a repo and task
- capture the run ID
- tail run events, optionally as JSON
- inspect the final run status
- cancel or retry only when the status supports it
The CLI wraps the v1 runs API and adds CI-friendly behavior such as JSON output, idempotency keys, event following, and exit-code-mapped errors.
Typical command shape
export MOGPLEX_API_KEY="mog_..."
RUN_ID=$(
mogplex run --repo "$MOGPLEX_REPO" --create-branch --json \
"Investigate the failing test and propose the smallest fix." \
| jq -r '.runId'
)
mogplex runs events "$RUN_ID" --follow --timeout 900
mogplex runs get "$RUN_ID" --jsonFor the exact flags, output fields, idempotency behavior, and event format, use CLI Automation: Headless Runs.
Requirements
- a Mogplex API key with the right scope
- a repo ID from Mogplex, not only an owner/name string
- a clear task prompt suitable for unattended execution
- timeout and final-status handling in the calling script
Use read-only tokens for dashboards that should inspect runs but never start or cancel them.
Where to inspect results
Use Observability after the run starts if you need:
- model calls and token usage
- tool calls and errors
- sandbox linkage
- pressure or queue signals
- cost and duration
Use the API pages when another system needs to consume the same run data: Runs API, API Errors, and Working Requests.