/v1 API. Use it
from a terminal, shell script, CI job, or coding agent.
The CLI has no database, provider credential, worker, or deployment access. It
does not call private application routes.
The public
@openpmm/cli package is available on npm. Its source, tests, and release workflow are also public.View source on GitHub
Audit the complete source, tests, and release workflow.
Authenticate the CLI
Sign in through your browser and approve a Workspace.
Install or run once
Run the CLI without an installation:openpmm command globally:
openpmm is not found, compare the npm bin
directory with your PATH:
<npm-prefix>/bin to PATH, or use the pinned npx command.
Run from source
You can also run the audited source:Common workflow
signup_url
and returns immediately. After browser approval, auth login --resume stores
the resulting credential and Workspace.
See Create an account.
Run openpmm --help to see the command tree. Run
openpmm <command> --help to see its API operation, scope, side effects,
input forms, complete flag list, output modes, exit codes, and a copyable
example.
Run a read-only compatibility check before automation:
workflows.draft.ready field checks the requirements for draft creation. The
workflows.publish.ready field also requires a ready Destination. A missing
Destination does not block draft creation. The command never prints the API
key.
For an agent workflow, treat openpmm as the complete CLI interface. Do not
read its credential file or use its key in another client. See
Agent workflow.
Customize the Writing Assistant
Read all seven effective Workspace refinement options:actions object in a JSON request file, then edit the
titles, full prompt templates, and icon keys. Keep all seven action keys and
send the complete replacement:
--etag to pin an update
to a version that you read earlier. See Refine post copy
for the web workflow and system prompt disclosure.
Public compatibility contract
Command names, flags, JSON fields, stdout and stderr behavior, and exit codes are public interfaces. Before1.0, a minor release can contain breaking
changes. After 1.0, breaking changes require a major release and a documented
deprecation when a safe compatibility path exists.