Disclosure: Tallyfy competes with several platforms named below and released its own CLI on July 16, 2026. Every vendor claim here was verified against live pages in mid-July 2026, and we link the sources so you can re-check us.

Here’s the short answer to the title: as of mid-July 2026, almost nobody. Among the workflow and BPM platforms we surveyed, not one ships a supported, first-party, general-purpose workflow automation CLI in the way Stripe or GitHub ship theirs. Camunda had one and let it go. n8n has a real one, but it lives on the server itself. Pipefy just shipped a beta. Nintex documents a CLI that only touches one corner of its product line. The rest offer REST APIs, SDKs, and webhooks, and stop there.

Our first draft was too confident. It said flatly that no vendor ships one. Then we checked each claim against live pages and got corrected twice, by Pipefy and by Nintex. The corrections turned out to be more interesting than the original claim, so this post keeps them in.

Why should an ops leader or a developer care? Because the command line is where repeatable work lives. Cron jobs, CI pipelines, migration scripts, AI agents running shell commands: none of them can click a button in a web app. A platform without a command-line surface is a platform your automation can only reach through hand-rolled API glue.

Start with the quality bar

Before judging workflow vendors, look at what a finished first-party tool feels like. Two exist that nearly every developer already knows.

The GitHub CLI manual opens with a one-line pitch: “GitHub CLI, or gh, is a command-line interface to GitHub for use in your terminal or your scripts.” The command grammar is noun then verb, gh issue create, gh pr checkout, gh repo clone, and it stays consistent across the whole surface. You guess a command and you’re usually right. That predictability is the entire product.

Stripe’s tool goes further into the messy parts of integration work. Its webhook listener forwards live events straight to your laptop: “Use the —forward-to flag to send all Stripe events in a sandbox to your local webhook endpoint.” One command, stripe listen —forward-to localhost:4242/webhooks, replaces a tunnel service, a test deployment, and an afternoon. Both tools are written in Go, 99.6% for the gh repo and 97.7% for Stripe’s by GitHub’s own language stats, and install as standalone executables rather than dependency trees.

Neither company sells workflow software. That’s sort of the point. Payments and code hosting decided years ago that a scriptable surface was baseline equipment, not a bonus feature. Workflow automation, an industry whose whole pitch is repeatability, mostly hasn’t.

Who actually ships a workflow automation CLI?

Four vendors have something real to show, with big asterisks on each.

Camunda is the cautionary tale. Its zbctl tool was the canonical way to poke a Zeebe engine from a terminal, and Camunda deprecated it in 2024: “Starting with Camunda 8.6 (releasing October 8, 2024), we will no longer release new zbctl and Go client features.” The tool didn’t die, it changed hands. It moved to what Camunda calls community-maintained status, the repo sits in the camunda-community-hub GitHub organization, and Camunda’s own docs URL for the CLI client lands on that community page when you follow it. A once-official tool became a volunteer project. If you build on zbctl today, you’re building on goodwill.

n8n, the self-hostable automation tool that grew up in the connector era, has the most substance here and the most caveats. Its Server CLI does real work, with export:workflow and import:workflow commands that move workflow JSON in and out for backups and version control. The catch sits in the name: it “runs on the same machine as your n8n installation.” It’s an admin tool for the box, not a client for the service. In 2026 n8n also added a separate remote n8n CLI that talks to a running instance over the API, and then fenced it in themselves: “Use it only for experimenting, local development, and personal projects and not for production workflows.” Credit for shipping it. The production door stays closed for now.

Pipefy surprised us. Hidden inside its AI toolkit monorepo is pipefy-cli, an official command-line client with rich terminal output, a —json flag for scripts, and a —yes guard on destructive commands. The current release line is v0.2.0-beta, and the docs say PyPI becomes the canonical source at v1.0. So the accurate sentence is not “Pipefy has no CLI.” It’s “Pipefy shipped a beta CLI in 2026 as part of an AI toolkit.” Watch this one.

Nintex documents a real CLI on its own help site, but read the scope line closely: “skuid is a command line interface (CLI) for retrieving and deploying Nintex Apps objects (data and metadata) on Nintex Apps sites.” Skuid came in through acquisition and serves the app-building product; it shuttles app configurations between sandbox and production. Nothing wrong with that. It just isn’t a workflow CLI, and as of mid-July 2026 we found no equivalent for the core Nintex automation cloud. We wrote more about the wider platform in our Nintex review.

The empty column

Now the vendors where we found nothing, stated carefully, because absence is the easiest thing to get wrong.

Process Street’s integrations page documents a REST API, native webhooks that fire from workflows and forms, and connections to thousands of apps through middleware platforms. No command-line tool appears there or anywhere else we could find in its developer material as of this writing. Kissflow’s developer portal covers REST APIs and a JavaScript SDK, nothing terminal-shaped. ProcessMaker’s documentation leads with script executors, connectors, and AI form generation; the only command-line references we found were legacy server-administration commands on self-hosted installs, which is framework tooling, not a product CLI.

Three fairness notes before anyone sharpens a pitchfork.

First, these are point-in-time observations, checked in mid-July 2026, and this market moves. Pipefy proved that a “no CLI” row can flip to beta within a quarter. Second, we can only search public developer docs, so “we found none” is the strongest claim we’ll make. Third, the omission is a rational choice, not laziness.

These platforms sell to operations teams and citizen developers who build in a browser. A terminal tool serves a buyer most of them haven’t courted. If your team never opens a shell, a missing CLI costs you nothing, and a decent REST API covers the occasional script. The gap only bites when automation becomes a daily habit rather than a quarterly favor from IT.

Does shipping a CLI make a platform better at workflow? No. It makes the platform reachable from the places work already runs, which is a different virtue.

Why the gap is closing now

Two forces are dragging workflow vendors toward the terminal whether they like it or not.

The first is CI/CD culture spreading beyond software teams. Once a company treats its onboarding process or its compliance checklist as versioned configuration, someone asks the obvious next question: why can’t this live in git and deploy through a pipeline like everything else? JSON export, diff, review, import. That whole loop wants a command line.

The second force is AI agents. Agents operate tools through two channels, conversation-shaped protocols like MCP and plain shell execution, and the shell channel is the deterministic one. An agent that can run a command with a —dry-run flag, read structured JSON output, and check an exit code is auditable in a way that screen-clicking automation never will be. We’d argue the industry is building reasoning capacity faster than it’s building the rails that reasoning needs to run on, and a scriptable workflow surface is exactly that kind of rail.

Quick step back, though. A rushed CLI can be worse than none, because scripts encode assumptions and break silently when output formats drift. Which is why the next section is a test you can run on any of these tools, ours included.

How to judge a workflow CLI before you depend on it

Six checks, roughly in the order failures hurt.

1. Auth model. Ask where the token lives. A tool that stores credentials in an OS keychain, with an environment variable path for CI, beats one that writes a plaintext config file and calls it a day. Check what happens on a headless runner where no keychain exists.
2. Output formats. Human tables are for demos. Scripts need —json at minimum, and CSV or NDJSON if you feed spreadsheets or log pipelines. If parsing requires regex against pretty-printed text, walk away.
3. Dry-run. Look for a preview of mutations before they execute. A —dry-run flag that prints intended API calls turns a scary bulk operation into a reviewable diff.
4. Bulk operations. Launching one process from a terminal is a demo. Launching 400 from a CSV is a Monday. Look for batch inputs and for behavior on partial failure, because item 217 will fail eventually.
5. CI gates. The killer feature for pipelines is blocking on a human decision. Something like a wait command that polls until a named approval completes, then exits 0 or nonzero, lets a deployment pipeline pause for sign-off without a single custom script.
6. Multi-tenancy. If you manage several organizations or environments, the tool needs a first-class org switch, both as saved state and as a per-command flag. This one is routinely skipped: the request to add tenant support to Camunda’s zbctl sat as Zeebe issue 15100 and closed as not planned.

All six checks collapse into one property: determinism. Same input, same behavior, same exit code, forever. Everything else is decoration.

Where the Tallyfy CLI fits, and where it doesn’t yet

The biggest lesson we’ve learned building Tallyfy since 2014 is that the unglamorous surfaces earn the deepest loyalty, so we finally built the wrench. The Tallyfy CLI is a Go binary (99.1% Go, since we teased everyone else’s language stats) for macOS, Windows, and Linux. Version 0.1.0 shipped on July 16, 2026, which makes it days old as we write this. We’ll say that plainly instead of hiding it: there are no adoption numbers, no battle scars, no case studies. There’s a design and a binary you can test against the checklist above.

Against that checklist: tokens go to the OS keychain with an AES-256-GCM encrypted file fallback, and TALLYFY_API_TOKEN covers CI. Output is table, JSON, CSV, or NDJSON via one -o flag. A global —dry-run prints intended API calls without executing. tallyfy process launch starts one process or many from a CSV. tallyfy task wait blocks until a named task completes, which is the CI approval gate. And —org switches organizations per command, with tallyfy org use for saved state.

Blueprints export to git-committable JSON and import across organizations, the same pattern n8n validated for workflow definitions. There’s also a raw tallyfy api escape hatch for endpoints we haven’t wrapped, because pretending v0.1.0 covers everything would be rubbish.

The design choices borrow deliberately from tools we admire, and we documented that lineage, including a security bug our own review caught, in a separate post on how Claude Code’s configuration architecture shaped the CLI. Skeptical is the right way to arrive at any v0.1.0, so bring the checklist and file issues when we fail it.

One prediction to close. Within two years, a first-party CLI will be a standard line in workflow RFPs, the way API access became one a decade ago. The vendors above that already publish APIs have done the hard part; wrapping one in a command grammar is the cheap part. The scarce thing, turns out, is deciding that the terminal buyer matters. In an era when your next “user” might be a pipeline or an agent rather than a person in a browser, that decision is overdue across the category, and we’d rather compete on execution than on whether the category should exist.