cwp db pull

cwp db pull [env] [flags]

Acts on the local site. Name an environment to act there instead.

site → local

Argument	What it is	Default
[env]	environment to pull from

Flag	What it does	Default
--no-scrub	skip data scrubbing (the mail guard is still installed)	on
--no-snapshot	skip the local database snapshot taken before the import	on
--yes	skip the confirmation prompt	off
--with-agent	with —dry-run on a host with no shell: install and remove the PHP agent so the plan is real	off

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

What it does

cwp db pull exports the environment’s database and brings the dump down. It snapshots the local database and imports the dump. It rewrites the environment’s URL to the local one with wp search-replace. It scrubs personal data unless you pass --no-scrub. It installs the mail guard either way.

The captcha keys arrive with the options table too, and both are wrong here. The environment’s site key names a widget registered for that host. That widget refuses the DDEV one. The secret has no business on a laptop. So every pull that imports a database writes the vendor’s sandbox pair into the builder’s Turnstile slot. It does so whatever came down and whether the slot was empty:

✓ captcha — turnstile sandbox keys (every submission passes locally)

A form with the captcha switched on shows the widget locally and lets every submission through. The step is fatal, like the mail guard: a pull that could not write the pair leaves the production secret in the local database and says so. cwp doctor names the pair on both sides.

The options table arrives whole, and two rows in it belong to declarations rather than to the environment. The pull puts both back after the import:

• Availability. When access: declares a mode for local, the pull converges the local site to it, the same write cwp access makes. Without a declaration the environment’s flag stays, and a closed environment gives you a closed local site.
• Plugin activations. The pull switches back on a plugin that inventory.yml scopes to local with environments: [local] and records as active. The run names every other plugin whose state the import changed. The import’s answer for it stands.

Both are effects in the plan, so --dry-run names them.

What it does not do

It does not bring the uploads; that is cwp media pull. It does not push a database anywhere: the database flows downward only.

It does not re-activate an unscoped plugin. A plugin without environments: belongs everywhere, and the environment’s database is the authority on its state. The run says what changed, and wp plugin activate is one command away.