Local verification threat model
What Critique isolates during local review, what it does not, and when to use cloud execution.
Local Critique review separates repository state and model conversations. It does not turn a local Git clone or worktree into a compute sandbox.
Security boundary
| Boundary | Local guarantee | Consequence |
|---|---|---|
| Source working tree | Review and repair operate in a disposable clone or worktree lease. A patch reaches the source tree only after git apply --check and successful verification. | Reviewer scratch files and failed repairs do not modify the source tree. |
| Verifier state | The verifier receives a reset candidate plus the proposed patch, in a fresh conversation. | Repairer scratch state is not inherited. |
| Model independence | Strict verification requires a different model family and disables verifier prompt-cache reuse. | If that configuration is unavailable, apply fails closed instead of claiming independent verification. |
| Untrusted code execution | A local clone/worktree is filesystem isolation only. Processes still run with the caller's operating-system identity. | Do not run untrusted repository scripts locally. Use Critique Cloud or another policy-enforced sandbox. |
| Secrets | Handoffs, prompts, events, evidence, patches, and review memory are redacted. Selected local test environment files exist only in the disposable workspace. | Repository code executed locally could still read resources available to the caller; use test-only credentials. |
Pooling does not weaken the trust model
The optional workspace pool shares a read-only Git object store. Each critic, repairer, and verifier receives a distinct disposable worktree. Pooling avoids repeated object copies; it does not share mutations, conversations, evidence authority, or verifier state.
The pool is disabled unless CRITIQUE_WORKSPACE_POOL_V1=1. If it is unavailable, Critique falls back to isolated temporary clones.
Safe defaults
- Quick review is capsule-only and does not execute repository tools.
- Deterministic evidence is marked
critique_executedonly when the runner attests sandbox isolation and the exact workspace digest. - Author-reported commands remain
author_supplied; they cannot satisfy an acceptance criterion. - Budget exhaustion and infrastructure failures produce
INCOMPLETEorUNVERIFIABLE, never a green verdict. - Cloud verifier commands run in a credential-free sandbox separate from model inference.
Use separate test accounts, databases, and API keys for any repository validation. Never expose production credentials to review workloads.
Independent verification protocol
Native Critique operations, evidence trust, state binding, completion proofs, event streaming, and compatibility with finish.v1.
Critique reviewer runtime
How the Critique CLI owns its pinned OpenCode runtime, model roles, evidence capture, and repository review configuration.