Commands
shipped 1.0.0Every command, its arguments and its flags, read from the CLI’s own manifest rather than written here. A flag on one of these pages is a flag the binary has. The two come from the same file.
| Command | What it does |
|---|---|
cwp init | Scaffold a cwp project (interactive, safe to re-run) |
cwp doctor | Run read-only environment diagnostics |
cwp adopt | Declare that this project manages an environment, and give its content identity |
cwp pull | Read an environment’s state down into the committed tree |
cwp push | Converge an environment to the committed tree |
cwp deploy | Converge an environment to the tree, then run the remote post-steps and post-deploy hook |
cwp launch | Run the launch checks against an environment, and set its stage to live when every one passes |
cwp configure | Walk the declaration with evidence from the site: a proposal per section, a yes per write, a reason beside each line |
cwp status | Show project, environments, DDEV state, last pull, snapshots and drift |
cwp log | What happened to an environment: pulls, pushes, refusals, and how to get back |
cwp db | Local database snapshots, import and export |
cwp media | The files an attachment points at |
cwp fetch | Fetch third-party themes and plugins down from an environment |
cwp content | Move individual pages and posts between an environment and the committed tree |
cwp bricks | Bricks 2.4 operations: the design system, MCP wiring and builder post types |
cwp settings | Move declared WordPress options between a site and the committed tree |
cwp widgets | Move widget areas between a site and the committed tree |
cwp roles | Move roles and their capabilities between a site and roles.yml |
cwp inventory | Record and reproduce what this site runs on (inventory.yml) |
cwp perimeter | Converge who comes through which door of a site to what cwp.yml declares |
cwp edge | Read, converge and compare the settings of the edge in front of an environment |
cwp coverage | Measure what the site holds and the committed tree does not |
cwp scrub | Remove production personal data from the local copy |
cwp wp | Run WP-CLI locally or on an environment (everything after -- is forwarded verbatim) |
cwp shell | Open an interactive shell in the local container or on an environment |
cwp tail | Tail the local container’s log, or an environment’s |
cwp open | Open the site in a browser: the local DDEV URL, or an environment’s |
cwp abilities | List the abilities registered on a site, and what each one declares |
cwp ability | Call one ability by name (guarded per its own readonly/destructive annotation) |
cwp mcp | Generate the MCP client config for an environment, minting an application password |
cwp serve | Serve every command as an MCP tool over stdio; a write answers with its plan, and cwp_apply runs it only in build |
cwp agent | The PHP agent a host with no shell answers through |
cwp projects | List the projects registered on this machine (no remote calls) |
cwp config | Read and write project (cwp.yml) or machine configuration |
cwp plugins | The former name of cwp inventory, kept as an alias |
cwp logs | Renamed: see cwp tail |
cwp access | The former name of the site door of cwp perimeter, kept as an alias |
37 top-level commands, 78 pages in all, read from the manifest of cwp 1.0.0.
Three things that hold for the whole surface
Human output goes to stderr, machine output to stdout. --json prints one
envelope on stdout and nothing else, so a shell pipeline and a person reading
the terminal never contend for the same stream.
Every command that acts shares --json, --verbose and --dry-run.
Three commands have no --json: cwp wp, cwp shell
and cwp logs. They hand the terminal to another program, and an
envelope wrapped around its output would corrupt the thing you asked for.
Commands that change nothing accept --dry-run and ignore it.
Every command runs inside a project except cwp projects,
which answers a question you ask from anywhere.