cwp bricks

cwp bricks [flags]

cwp bricks groups the commands below and takes no action of its own; run it alone and it prints its help.

Subcommand	What it does
cwp bricks pull	Pull the Bricks design system down into bricks/ as a tree of JSON
cwp bricks push	Push the bricks/ tree to an environment (an upward write against a remote)
cwp bricks audit	Report design-system rot: orphan references, unused classes, variables and colours
cwp bricks post-types	Which post types the Bricks builder opens for (bricks_global_settings.postTypes)

What it does

The design system, the MCP wiring and the builder’s post types. Requires builder.id: bricks in .cwp.yml; cwp doctor checks the whole chain before you need any of it.

Omitting the environment means the local DDEV site, exactly as with cwp open. The environment map in .cwp.yml describes your remotes; the local site is not in it, and it is the one you normally point a builder client at.

Unlike cwp wp, cwp shell and cwp logs, this is not a pass-through: each subcommand has an opinion about guards and output, so all of them take --json, --dry-run and --verbose.

How cwp talks to Bricks

Through Bricks’ own 145 abilities, invoked over a PHP shim piped into wp eval-file - on whichever conduit the environment needs. You do not need the WordPress MCP Adapter plugin for any of this — the abilities are WordPress core’s Abilities API and exist without it. The adapter is what lets an AI client reach them over HTTP, which is why cwp mcp is the one command that checks for it.

Two consequences worth knowing:

• It runs as a WordPress user. Every ability tests the current user and WP-CLI has none of its own, so cwp resolves one: builder.options.wp_user if you set it, otherwise the first administrator. On a site with several admins, or on production where you want a dedicated service account, set it explicitly.
• It needs Bricks ≥ 2.4, WordPress ≥ 6.9 and the Bricks AI surface switched on. Bricks registers no abilities at all when that toggle is off or BRICKS_DISABLE_MCP is set in wp-config.php, so cwp bricks cannot reach a site in that state. cwp doctor names which of the four causes applies, because the fixes are entirely different.

Two commands that used to live here

cwp ability and cwp abilities and cwp mcp are top-level now, for the same reason: the mechanism underneath them turned out not to be Bricks’. The transport is WordPress’s own Abilities API, and what mcp wires up is an environment and a credential, which every site has.

What it does not do

It does nothing on a project whose builder.id is none, and says so rather than failing obscurely.

It is not a Bricks installer, and it does not switch the AI surface on for you — that is a setting in the Bricks admin, and flipping it from a CLI would be a change to a live site nobody asked for.