cwp status

cwp status [env] [flags]

Acts on the local site unless an environment is named.

Argument	What it is	Default
[env]	environment for the remote column	dev

Flag	What it does	Default
--drift	compare the local site against the committed tree	off
--remote	compare an environment as well (implies —drift)	off

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

What it does

The “where am I in this project” screen, so the answer does not need ddev describe, cat .cwp.yml and cwp db list separately.

$ cwp status
✓ project — example.com — ~/Code/example/example.com
✓ docroot — public
✓ php — 8.3
✓ environment dev — https://example.com — app example.com — managed
– ddev — not running — https://example.com.ddev.site once started with `ddev start`
– last pull with a snapshot (dev) — unknown — no pre-pull snapshot on disk. A pull with --no-snapshot or --uploads-only leaves none, and `cwp db rm` removes the record with the restore point
– snapshots — none in ~/Code/example/example.com/.ddev/db_snapshots
! bricks — repo ? — not a git repository, or git did not answer
– content/ — repo – — no `content:` block — this project does not move pages
– plugins.yml — repo – — no plugins.yml — run `cwp plugins snapshot`
  only the repo column was read — pass --drift to compare the local site, --remote to compare an environment as well

_{Captured from cwp 1.0.0. Not written by hand.}

It makes no remote calls at all unless you ask for them. It reads the config, the DDEV state, the snapshot directory and git status — nothing else. It has to be instant and has to work on a train, with Docker stopped and no login anywhere. cwp doctor is the command that talks to the remote and takes as long as that costs.

Drift: is what you have what you committed?

The last lines are one per tracked artifact, and by default they answer one question — is that tree committed?

✓ bricks — repo ✓
✓ content/ — repo ✓
✓ plugins.yml — repo ✓
  only the repo column was read — pass --drift to compare the local site,
  --remote to compare an environment as well

--drift adds the local column: does the site on this machine hold what the tree says? --remote adds a third for an environment, and implies the first.

✓ bricks — repo ✓ ═══ local ✓ ═══ prod ✓
! content/ — repo ✓ ═══ local ✗ ═══ prod ✓ — 2 of 8 page(s) differ on local
! plugins.yml — repo ✓ ═══ local ✓ ═══ prod ✗ — 2 difference(s) on prod

Both are flags because both cost something, and that is the whole reason this check can live here: the remote column needs the network and the local column needs a running container. A bare cwp status stays half a second.

A cell reads ✓ agree, ✗ differ, – this project has no such artifact, and ? asked and could not be answered — Docker stopped, a remote that did not reply, a tree that could not be read. ? is never rounded to either side, and a run with one of them says so rather than closing with “everything agrees”.

Each artifact is compared with the machinery that moves it: the same drift calculation cwp content status reports per page, the same diff cwp plugins apply acts on, the same export cwp bricks pull writes. cwp status has no second opinion about what “differs” means.

Drift warns, never fails. It is a fact about a project rather than an error in it, and a command that exited non-zero because a page was unpushed would be unusable in the loop it exists to serve.

The last pull is read off the snapshots

Not from a state file cwp would otherwise have to write, gitignore and keep consistent: every pull leaves pre-pull-<env>-<timestamp>, so the restore point already records both when and from which environment. That reading has three limits, and the output says “last pull with a snapshot” because of the first:

1. A pull with --no-snapshot or --uploads-only leaves no snapshot and is invisible here.
2. cwp db rm on a pre-pull-* snapshot deletes the record along with the restore point — reclaiming disk space quietly rewrites this history.
3. The snapshot is taken before the import, so it proves a pull got past the confirmation guard, not that it finished. A pull that died on the transfer leaves the same trace as one that succeeded.

An environment with no pre-pull-* snapshot is therefore reported as unknown with the reason — never as “never pulled”, which cwp cannot know.

What it does not do

It contacts no remote unless you pass --remote, starts nothing, and writes nothing to git: the repo column is a git status, and cwp never stages, commits or branches on your behalf.

--dry-run is meaningless here and is ignored, exactly as cwp doctor ignores it.