cwp roles push

cwp roles push [env] [flags]

This name is an alias. The work moved to cwp push --only roles, and that page documents it. This spelling still runs for one minor cycle.

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

tree → site

Argument	What it is	Default
[env]	environment to write (default: default_environment in cwp.yml)

Flag	What it does	Default
--prune	also revoke capabilities and delete roles the file omits	off
--force	override the protected-environment refusal	off
--no-backup	skip the remote backup taken before the write	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

Makes a site grant what roles.yml describes: creates roles that are missing, grants capabilities that are missing, and renames a role whose display name differs.

Against a remote it is an upward write under the full guard set: every change listed first, the protected environment refusal, a backup unless waived.

Additive unless you ask otherwise

A capability the site grants and the file does not describe is reported and left alone, and so is a role the file does not mention. --prune revokes and deletes.

The asymmetry is sharper here than for plugins. Being wrong in the removing direction locks somebody out of their work. The same mistake with a plugin leaves it installed. A run that would take a permission away says so in the confirmation, in those words.

cwp compares WordPress’s own roles and never pins them. Core adds capabilities in a release; a file that asserted administrator downward would fight every update.

What it does not do

• It does not touch users. Removing a role under --prune leaves the people who held it with no role. Putting the role back undoes that; losing the users would have no undo.
• It does not push what it was not given. No roles.yml is a refusal naming the pull, not an empty write.