cwp bricks pull

cwp bricks pull [env] [flags]

Acts on the local site unless an environment is named.

Argument	What it is	Default
[env]	environment to pull from (omit for the local site)

Flag	What it does	Default
--type <type...>	restrict to these transfer types (default: everything with content)
--sensitive	include the api-keys and custom-code settings tabs	off

Plus the shared flags --json, --verbose and --dry-run.

What it does

Writes Bricks’ own transfer package into builder.options.export_dir — bricks/ by default — as a tree of JSON: manifest.json, styles/classes/classes.json, structure/templates/template-*.json.

That tree is the thing you commit. The ZIP Bricks produces is transient; the tree is what a diff can be read on, and it is what makes an upward design change reproducible rather than remembered.

The api-keys and custom-code settings tabs are left out, and the run says so. That is not a formality: this tree goes into git, and an export that quietly carried your API keys there is a different category of mistake from one that overwrote a class. --sensitive includes them, and nothing else implies it.

Scope is always explicit — every item is named by ID, and ["all"] is used only for genuinely single-value types such as breakpoints.

Example

cwp bricks pull                                # everything with content, from local
cwp bricks pull --type classes --type variables
cwp bricks pull prod                           # read a remote instead

What it does not do

It deletes nothing. Like cwp push without --delete, it is additive: files in bricks/ that this export no longer contains are reported and left alone, because removing a git-tracked file is not a side effect of an export.

It writes nothing to the site it read from. Reading a remote is safe, which is why an environment argument here carries no guard ladder.