The desktop app is the daily driver. The CLI is what you reach for when you want SiteCMD inside an automated pipeline: a CI job, a pre-push hook, a deploy gate, a cron-driven scan.

The sitecmd binary runs the same live-site checks as the desktop app, but with no UI, no database persistence (by default), and no auth. It’s a single static binary built for Linux, macOS, and Windows.

This page is the reference: what every command does, every flag, every exit code. For task-oriented usage, see Quality gates in CI and Pre-push hooks.

Installation

Downloads aren’t open yet. SiteCMD is in pre-launch. Get on the launch list at /download. The CLI ships at the same time as the desktop app.

At launch, the CLI is available three ways:

Bundled with the desktop app. Install the desktop app and the sitecmd CLI lands in your $PATH.
Standalone binary. Direct download for Linux, macOS, and Windows. Use this on CI runners that don’t need the GUI dependencies.
Docker image. For embedding the CLI in containerized pipelines.

Commands

The CLI exposes five subcommands:

Command	What it does
`init`	Set up a `.sitecmd/` project config in the current directory.
`scan`	Run a scan and write results to `.sitecmd/` (or stdout with `--json`).
`fix`	Output fix prompts from the last scan.
`watch`	Re-scan on an interval.
`check`	Regression check designed for git hooks.

Run sitecmd <command> --help for the full flag list per command.

`sitecmd init`

Bootstraps a .sitecmd/ directory at the project root.

sitecmd init [url] [options]

Flag	What it does
`[url]`	Positional. The site URL for this project.
`--name <NAME>`	Project name (defaults to the directory name).
`--yes`, `-y`	Non-interactive mode (use detected values without prompting).
`--no-deep-link`	Skip opening the desktop app after init.

The .sitecmd/ directory it creates contains:

config.json — project URL, default scan type, environments, thresholds
last-scan.json — the most recent scan result (created after the first sitecmd scan)
history/ — older scan results, used by --diff

Commit .sitecmd/config.json so your team and CI share settings. The result files (last-scan.json, history/) are typically gitignored.

`sitecmd scan`

Runs a scan against the configured (or passed) URL.

sitecmd scan [options]

Flag	What it does
`--url <URL>`	URL to scan. Falls back to `.sitecmd/config.json` if omitted.
`--type <TYPE>`	Scan type: `health`, `security`, `accessibility`, `polish`. Default: `health`.
`--diff`	Compare with the last scan and show what changed.
`--env <NAME>`	Use a named environment URL from config.
`--fail-under <N>`	Exit 1 if the score is below N. The quality-gate flag.
`--json`	Output JSON to stdout, skip writing to `.sitecmd/`.
`--output json`	Alias for `--json`.
`--timeout <SECS>`	HTTP timeout per request. Default 30s.
`--categories <LIST>`	Comma-separated category filter.
`--no-browser`	Skip browser-based checks (axe-core, Core Web Vitals).
`--cwv`	Measure Core Web Vitals via headless Chrome.

Exit codes

Code	Meaning
`0`	Scan passed (or no threshold set).
`1`	Score below the `--fail-under` threshold.
`2`	Scan error (network problem, invalid URL, etc.).

These exit codes are the basis for every CI integration. See Quality gates in CI.

Examples

# Scan with current config
sitecmd scan

# Scan a specific URL
sitecmd scan --url https://example.com

# Quality gate: fail the build if security score drops below 90
sitecmd scan --type security --fail-under 90

# Diff against last scan
sitecmd scan --diff

# Pipe results to a file for further processing
sitecmd scan --json > results.json

`sitecmd fix`

Outputs fix prompts from the most recent scan.

sitecmd fix [options]

Flag	What it does
`--all`	Show all issues (default: top 5).
`--id <CHECK_ID>`	Show the fix for a specific check ID.
`--type <TYPE>`	Filter by issue type.
`--category <CAT>`	Filter by category.

Useful for piping into an AI tool from a script, or for printing a quick to-do list after a CI scan.

`sitecmd watch`

Re-scans on an interval. Useful when you’re actively fixing issues and want to see them tick down.

sitecmd watch [options]

Flag	What it does
`--url <URL>`	URL to monitor.
`--interval <SECS>`	Rescan interval. Default 300s (5 minutes).
`--env <NAME>`	Use a named environment from config.

`sitecmd check`

Regression check designed for git hooks.

sitecmd check [options]

Flag	What it does
`--install`	Install as a git `pre-push` hook.
`--strict`	Fail on any new issue, not just score drops.
`--threshold <N>`	Minimum score to pass (defaults to the value in config).

See Pre-push hooks for the recommended setup.

Core Web Vitals

sitecmd scan --cwv

Measures Core Web Vitals (LCP, FID, CLS, TTFB, INP) by spinning up a headless Chrome instance. Adds time per scan (typically 5-15s per page), so it’s usually a nightly or release-gate flag, not a per-commit one.

If your CI runner doesn’t have Chrome installed, this flag will fail. Use --no-browser to explicitly skip browser-based checks.

Authentication and data

The CLI doesn’t require a login. It doesn’t talk to a SiteCMD server. It writes results to the local .sitecmd/ directory and exits.

Two consequences:

Free-tier features only. Cross-source correlation, fix guides with framework-specific steps, AI fix prompts, ticket mirroring, and other tier-gated functionality require the desktop app and an active license.
No shared history. The CLI’s .sitecmd/ directory is local to wherever it ran. If you want shared history across machines, run the desktop app on one machine and use the CLI for ephemeral CI checks.

When to use CLI vs. desktop

Use the desktop app for	Use the CLI for
Day-to-day triage	CI quality gates
Reading scan results in detail	Headless scans on schedules
Connecting integrations	Pre-push git hooks
AI editor workflows (via MCP)	Build pipelines
Long-running history	One-shot regression checks

The two are designed to coexist. Many teams run the desktop app locally for triage and the CLI in CI for enforcement.