Version: v5.7.0

opschain admin workflows destroy

Included from Basic tier

opschain admin workflows destroy <project>/<code> [--with-runs] [--yes]

Permanently destroys a stored workflow: the workflow row and all its versions are removed, and with --with-runs its runs, their workflow steps and their log data (lines and stored log blobs) go too. This is the clean-up verb for obsolete workflows that archive alone leaves cluttering the archived list; archiving stays the right answer whenever the history should remain browsable. In the GUI the same destroy is Destroy with runs… on an archived workflow: the manifest preview, then a typed confirmation.

The guard rails, in the order the server checks them:

Archived first. A live workflow is refused by name — archive it with opschain workflows archive, then destroy. Destroying is a deliberate two-step operation, like the node delete → destroy lanes.
No active runs. A run still pending/queued/running/waiting refuses the destroy even with --with-runs — wait for it or cancel it first.
Nothing in the automation plane references it. Scheduled activities and triggers that target the workflow refuse by count; remove them first — the destroy never cascades into automation.
Runs need --with-runs. Without the flag, N runs reference this workflow — pass with_runs to destroy them too, or leave it archived.

What survives, by design: events (the audit trail and chain views are never touched, and the destroy itself appends an api:workflows:destroyed event recording who destroyed what — code, versions and runs counts); nested changes the runs spawned (they are ordinary change history on their own nodes — only the linking workflow-step rows are removed); and other workflows' runs that nested this workflow (their steps' nested-run links are cleared, the runs themselves survive).

The command fetches the destroy manifest first and prints what will be removed:

will permanently destroy workflow demo/release:
  log_lines        41
  runs             2
  versions         3
  workflow_steps   5
events are retained — the audit trail persists; nested changes stay as change history
permanently destroy workflow demo/release (3 versions, 2 runs)? [y/N]:

Without --yes it prompts on the terminal (default No); with no terminal it refuses with the --yes instruction. After the destroy the same manifest prints under destroyed <project>/<code> — removed:.

Flags

Flag	Meaning
`--with-runs`	Also destroy the workflow's runs, their workflow steps and their logs. Without it, a workflow with runs is refused by name.
`--yes`	Destroy without the confirmation prompt (required when stdin is not a terminal).

Exit codes

Code	Meaning
0	Destroyed, or aborted at the prompt.
1	The server refused (not archived, active runs, referencing runs/triggers/scheduled activities, missing, authorisation).
2	Usage error — malformed address, no server target, no terminal without `--yes`.

Named errors

Server refusals pass through verbatim:

Cannot destroy workflow "<code>" — it is not archived. Destroying is a two-step operation: archive the workflow first, then destroy it
N runs reference this workflow — pass with_runs to destroy them too, or leave it archived
N runs of this workflow are still active — wait for them to finish or cancel them first
N scheduled activities reference this workflow — remove them first
N triggers reference this workflow — remove them first

CLI-side (exit 2):

expected <project>/<workflow-code>, got "…"
workflows need a server target — pass --server <url> or 'opschain context use <name>' (local mode has no workflows)
destroying workflow <project>/<code> is permanent — re-run with --yes to confirm (stdin is not an interactive terminal)

Examples

opschain workflows archive demo/old-release
opschain admin workflows destroy demo/old-release
opschain admin workflows destroy demo/old-release --with-runs --yes

-o json / -o yaml print the destroy manifest document (path, destroyed, counts).

Flags​

Exit codes​

Named errors​

Examples​

See also​

Flags

Exit codes

Named errors

Examples

See also