reference developer public

CLI reference

The DRC CLI is the shortest path from a local application to replayable evidence and service-level Signal runs. Install it through npm as described in Install DRC. Customer workflows use the installed drc binary directly. Run drc --help or drc <command> --help for the complete, current flag list for your version; this page explains what each command is for.

Global rules

Human output is the default and is intentionally compact.
Use --json for scripts, CI, and agents; human output and JSON are never mixed.
A failed operation returns a non-zero exit code.
IDs are stable handles; do not infer state from display formatting.

Commands

Account and access

Command	Use
`drc init [codebase]`	Initialize capture configuration for a codebase root silently on success. Writes the service identity and default-enabled telemetry policy into `.drc/drc.toml`; use `--service <name>` to name the service. Product telemetry privacy is controlled from the hosted account, not by an init flag. Safe to rerun; `--force` replaces an existing configuration.
`drc signup`	Create a free account on a DRC API server and sign in. Pass the password with `--password-stdin`.
`drc login`	Sign in to a DRC API server and store a local token.
`drc logout`	Remove the stored login token.
`drc whoami`	Show the signed-in identity without printing secrets.
`drc diagnose`	Check local CLI prerequisites and storage paths. Aliases: `doctor`, `check`.
`drc healthcheck --url <url>`	Check an HTTP health endpoint and exit non-zero when it is unhealthy.
`drc api-key` (`generate`, `revoke`, `list`)	Create, revoke, and list service-account keys. Only key hashes are stored; pass `--file` for the durable record.
`drc billing` (`plan`, `usage`, `portal`)	Show the current plan and limits, show usage, and open the Stripe Customer Portal.
`drc mcp`	Expose the local analysis engine over the Model Context Protocol for MCP clients such as Claude Code or Cursor.

Capture

Command	Use
`drc run`	Start the capture daemon. Proxies application traffic (`--port 8080` to `--target-port 3000`, plus repeatable `--extra-port`) or spawns the app itself with `--all-ports --app-command "npm start"`. Runs in the background.
`drc watch`	Stream events live from a running daemon. Use `--filter` to narrow by substring.
`drc stop`	Stop the daemon. Use `--flush` to write the buffer before stopping, `--force` for an immediate kill.
`drc capture`	Create a local capture session envelope for one service (`--service checkout`) with an `--output` storage root. Alias: `record`.
`drc search`	List captured executions. Filter with `--service`, `--time-range`, and `--state`; use `--format table` or `--format json`. Alias: `ls`.
`drc import`	Import telemetry from external systems. Subcommands: `datadog`, `splunk`.

Investigate

Command	Use
`drc trace <id-or-window>`	Show the causal chain of an execution: events, dependencies, and errors traced back to root cause.
`drc analyze <id-or-window>`	Run the local analysis pipeline: baseline replay, seven-layer divergence detection, and classification.
`drc replay <id-or-window>`	Replay an execution strictly. Modes: `strict`, `adaptive`, `mutated`, `approximate`. Apply a fix spec with `--fix` or a mutation with `--mutation`. Alias: `replay-exec`.
`drc diff <baseline> <candidate>`	Compare two executions and identify the earliest divergence. Alias: `compare`.
`drc bisect --baseline <id> --mutated <id>`	Binary-search events to find the minimal set that produces an error.
`drc blast-radius --execution-id <id>`	Scan all executions for the bug pattern found in a reference execution and show aggregate impact.
`drc fix [id-or-window]`	Confirm a fixed codebase resolves captured failures. `--dir` points at the fixed tree; defaults to the project root.
`drc counterfactual --execution-id <id> --modifications <file>`	Run what-if modifications against a captured execution and report which paths stay identical versus diverge.
`drc inject --execution-id <id> --injections <file>`	Apply virtualized state changes (clock, files, environment, DB, cache) to an execution. Alias: `inject-state`.
`drc chaos --execution-id <id> --spec <file>`	Apply chaos mutations across all virtualization layers. Alias: `layer-mutate`.
`drc regress --execution-id <id> --test-config <file>`	Promote a captured execution into a regression test and run it. Alias: `execution-as-test`.
`drc remediate [id-or-window]`	Run the self-healing pipeline: plan, counterfactual verify, execute, rollback on failure. `--daemon` runs it as a webhook server.
`drc reproduce [id-or-window]`	Generate a deterministic repro fixture from a captured execution. Languages: `rust`, `node`, `python`, `go`.
`drc mutate` (`create`, `validate`, `list`)	Create, validate, and list mutation specs used during replay.
`drc privacy audit <capture>`	Audit a capture against the local redaction policy (`.drc/redaction.toml`). `--fail-on-leak` exits non-zero when sensitive fields remain raw.

Command	Use
`drc push <id>` / `drc pull <id>`	Upload an execution to the hosted registry or download one. Use `--target` / `--source` to use a local storage root instead. Aliases: `upload`, `download`.
`drc share <id>` / `drc unshare <id>` / `drc shares list`	Share an execution with another user through the cloud, revoke a share, or list executions shared with you.
`drc incident export --execution-id <id>`	Produce a portable incident packet for handoff.
`drc governance`	Governance operations: `legal-hold` (create, list, release), `audit` (log, verify), `classification` (classify, rules), `compliance` (report, controls, findings).

Verification and deployment

Command	Use
`drc signal`	List configured services from `.drc/signal.yml`.
`drc signal <service>`	Run one configured service's Continuous Verification Signal and publish its bounded result.
`drc signal cv <service>`	Explicitly run CV for one service (candidate versus baseline replay and diff).
`drc signal cc ...`	Hosted Continuous Compliance operations: `check`, `run`, `status`, `history`, `show`, `sync`, `frameworks`, `controls`.
`drc signal cc` (`status`, `controls`, `sync`)	Read and reconcile hosted CC state without a local evaluation.
`drc gateway check`	Verify a deployment by comparing baseline and candidate executions, optionally blocking on cross-tenant forecast impact.
`drc gate evaluate`	Evaluate a candidate change against policy rules from the Evidence Control Plane.

Operator (self-managed deployments)

Command	Use
`drc server` (`start`, `worker`, `status`, `stop`)	Start the API server or a dedicated hosted worker, check server status, or stop it.

Continuous Compliance contracts

CC is separate from CV even though both are configured in .drc/signal.yml. Use the shared Signal command with the compliance subcommands:


drc signal cc frameworks
drc signal cc controls
drc signal cc status
drc signal cc history
drc signal cc show <evaluation-id>

Framework and control discovery reports the pinned version, technical-subset disclaimer, selected/evaluated counts, supported detector, required evidence, exact checks, and whether the control is included or requires a paid CC add-on. Unsupported controls are rejected by signal check and cannot run.

CC results expose only compliant or non_compliant. Detailed results include expected policy, observed values, evidence links, remediation, evaluator version, manifest hash, evaluated commit, environment, and blocker codes. The service-level wording is: "This service passed the selected machine-evaluable technical controls in the configured framework profile."

Examples


drc init --service checkout-api
drc run --port 8080 --target-port 3000
drc watch
drc stop --flush
drc search --format table
drc search --format json
drc replay exec_abc123 --json
drc diff exec_baseline exec_candidate --json
drc signal
drc signal checkout
drc signal cc status

Signal

Signal is the shared service workflow for Continuous Verification and Continuous Compliance. Configure both in .drc/signal.yml. Read Continuous Verification, Continuous Compliance, and Signal YAML reference.


# List services and whether CV/CC are enabled
drc signal

# Run one service's configured CV command
drc signal checkout

# Read hosted CC state; CC evaluation never runs locally
drc signal cc status
drc signal cc controls

drc signal <service> runs the service command from the YAML, captures bounded output, returns the command's exit status, and submits the service-tagged result when an active provider context is available. Repository, commit, workflow, run ID, and endpoint context are supplied by the installed integration. The user selects only the configured service.

The CC branch is intentionally separate: drc signal cc status and controls read the hosted compliance control/evaluation state. CC evaluates the configured service independently. Its precise user-facing result is either compliant or non_compliant: "This service passed the selected machine-evaluable technical controls in the configured framework profile."

The shared file supports services.<name>.cv, services.<name>.cc, and services.<name>.cache. Dependency caches are bounded runner acceleration only; DRC evidence and compliance records remain tenant-scoped and immutable.

Output contract

Human replay output reports the execution ID, mode, storage authority, events loaded, validation result, and events replayed. JSON includes machine-readable status and error fields. Zero events or an incomplete validation is not reported as a successful replay.

Time-window mode

Analysis commands can operate on a time window instead of one selected execution. Use a duration such as 24h, 7d, 30d, or 6mo as the positional target:


drc search 24h
drc trace 24h --limit 20
drc analyze 30d --limit 50
drc replay 6mo --limit 20

Window mode finds executions started in the window that contain an error or exception, processes them newest first, and caps the result at --limit. It returns one result per execution. Use --execution-id <id> when you want exactly one execution; an explicit ID and a time window cannot be supplied together. Commands that resolve a single target, such as drc fix 30d, use the newest matching failure rather than iterating every failure.

MCP clients use the equivalent since and limit arguments on trace, analyze, and replay.

Watch subcommands

Watching unfiltered traffic is intentionally not the default workflow. Use a scoped watch mode for an investigation or a bounded port capture, and stop it when the diagnostic window ends. Long-running observation should be configured with retention and redaction policy before it starts.

Initialization metadata

drc init records runtime = "port-runtime" and treats language as optional metadata. The universal-proxy path is selected from observed ports rather than a required language field. Multi-datacenter deployments can declare datacenter and replication-factor values; the replication factor cannot exceed the datacenter count. Initialization is safe to rerun, and --force is required before replacing an existing configuration.

Failure output

Validation failures return a non-zero exit code and identify the operation. Mutation validation, Classification, and Compliance report commands do not report success when their input is missing, malformed, or uses an unsupported framework.

Configuration

Run drc config get to inspect non-secret configuration. Token and private-key values are never printed. See Configuration reference for deployment settings.