CLI Reference

Commands, local working-tree semantics, review skills, models, repair modes, security, and automation for the Critique CLI.

The Critique CLI is the canonical Critique interface for developers and coding agents.

Command map

Command	Purpose
`critique login`	Approve a browser device or save a `crt_` machine key
`critique setup --local`	Check the provider-aware local runtime
`critique setup --with-chatgpt`	Authenticate the official Codex CLI
`critique finish`	Review the current working-tree change
`critique skills`	List all built-in, auto-selected review skills
`critique models`	Show the default and available cloud models
`critique model <id>`	Persist a default model
`critique integrate`	Install finish instructions for coding agents
`critique init`	Create repository review policy
`critique security`	Run the optional isolated Codex Security scan
`critique hook`	Install a pre-commit or pre-push finish gate
`critique history` / `proof` / `artifact`	Inspect prior results and evidence
`critique doctor`	Diagnose repository, runtime, and cloud readiness

critique finish compares the working tree with HEAD by default. It captures staged and unstaged tracked changes together, including deletions, plus bounded safe untracked text files. The capsule is content-addressed, redacts recognized secrets, records exclusions, and never mutates the source repository during review.

Each critic and verifier operates in a temporary clone at the capsule base commit. The patch and safe untracked files are materialized there. Repairs are prepared in another isolated workspace and verified in a fresh workspace before --repair apply may update the source tree.

Why use a fresh workspace?

Critique does not begin by reading the whole repository. It starts with the task intent, exact diff, changed paths, and repository instructions. Local OpenCode and Codex reviewers follow references into nearby code or tests only when the change makes that context relevant.

The disposable workspace is what makes the result independent and safe: validation can reproduce the exact candidate change without touching the caller's working tree, relying on leftover local state, or mixing a repair into unfinished work. It is not another coding agent taking over the repository.

Cloud execution uploads a protected snapshot of the full working tree, including uncommitted changes, to a remote sandbox and runs the relevant checks there. The cloud reviewer currently receives the patch plus sandbox test results; unlike local OpenCode and Codex review, it does not yet freely explore the full repository.

This also keeps pricing legible. Critique charges per executed finish stage; model inference is billed separately by the selected local runtime or cloud provider. A normal review usually runs one critic stage. A repair that is applied and independently verified can run three: critic, repair, and verifier.

Models

The default provider model is deepseek/deepseek-v4-flash-0731.

critique model deepseek/deepseek-v4-flash-0731
critique finish --model deepseek/deepseek-v4-flash-0731 --intent "Verify the change"

Provider IDs work with Critique Cloud and provider-aware OpenCode. The official Codex CLI uses its own bare model names; when the configured default is a provider ID, Critique lets Codex use its authenticated local default instead of forwarding an incompatible identifier.

Local or cloud?

Local is the default. Use it for the everyday “check this before I push” job. Critique works in a temporary copy on your machine, then removes that copy.

When you are signed in with critique login, local finish runs sync a usage summary (run id, outcome, check fee, optional tokens) to Account. Capsules and source code stay on the machine.

Use cloud when the point is a separate, clean machine: your laptop cannot run the project, you need another environment, or the calling agent is not on the machine with the runtime.

What you need	Command
Normal pre-push review	`critique finish --intent "Check my change"`
A clean remote machine	`critique finish --engine cloud --intent "Check my change"`
Remote tests with test-only secrets	`critique finish --engine cloud --cloud-env test --intent "Check my change"`

Cloud test environments

Run a cloud review:

critique finish --engine cloud --intent "Run the real tests against this uncommitted change"

If the tests need secrets, open Account, import a test-only .env as a named cloud environment, and add it to the command:
```
critique finish --engine cloud --cloud-env test --intent "Run the real tests against this uncommitted change"
```

Critique compresses the current working tree—including staged, unstaged, deleted, renamed, and safe untracked files—and uploads that snapshot for this run. The cloud sandbox unpacks it, receives the selected environment values directly as process variables, runs an appropriate project test command, and is then destroyed.

The reviewer receives the test result, never the secret values. Values are encrypted at rest, are not included in the uploaded source snapshot, are redacted from output, and are never placed in proof artifacts. Use a separate test database and test API keys. Do not import production credentials.

--cloud-env is intentionally explicit. It never uploads your local .env automatically.

Policy

critique init creates .critique/finish.json for durable constraints, time/cost budgets, and the optional security scan. Repository instructions remain part of the review context, but cannot widen Critique's permissions.

CI

Use critique ci --intent "..." --base <ref> --json with CRITIQUE_API_KEY for non-interactive runs. Cloud execution receives the redacted change capsule, never local environment files.