opschain runs reject

Included from Basic tier

opschain runs reject <run-id> --step <step-id> [--message <text>]

Rejects one waiting step of a server run — the step does not proceed, and the run handles the rejection per its definition. The run id picks the step family — a change's steps or a workflow run's workflow steps, with the same fall-through as runs show — and --step names the step; the answer posts the step's reject verb on API v2 (StepService.RejectStep, or WorkflowStepService.RejectWorkflowStep for a workflow run's step).

Find the waiting step's id in runs show <run-id> -o json: it is the step whose status_code is waiting. A step that is not waiting for this answer is refused by the server with its named error. Every answer is audited — --message is the place to say why.

This is a server verb. A local attached run's gates are answered on the terminal prompt instead.

Flags

Flag	Meaning
--step <step-id>	The waiting step's id (required).
--message <text>	Audit note recorded with the rejection.

Output

rejected step 0199c8aa-… of run 0199c81e-… — now error

-o json|yaml prints the answered step document; the step's new status is its status_code.

Exit codes

Code	Meaning
0	Answered.
1	The answer failed — unknown run, or the server refused it (step not waiting for this answer).
2	Usage error (missing --step, local target).

Named errors

• runs reject answers a server run's gates — pass --server <url> or 'opschain context use <name>' (local runs prompt on the terminal instead) — no server target (exit 2).
• required flag(s) "step" not set — exit 2.
• run "<id>" not found on the server — neither family knows the id (exit 1).

See also

• opschain docs cli/runs-approve and opschain docs cli/runs-continue — the other two answers.
• opschain docs cli/runs-show — find the waiting step.
• opschain learn 3.1 and opschain learn 4.1 — gates in the walkthroughs.