Work inside the developer's Git repository and inspect existing policy before proposing changes.
Run codetruss --version first. If it is missing, explain the prerequisite and obtain explicit consent before downloading or installing software.
Offer only the official install paths from https://codetruss.com/cli. Let the developer inspect a downloaded installer instead of piping it when they prefer an inspect-first flow.
Do not run --llm, codetruss auth login, or codetruss sync unless the developer explicitly requests that networked action. Never search for or print provider keys.
Do not broaden allow, remove deny, add --no-verify, or edit a receipt to manufacture a green verdict. Fix the change or ask the developer to approve a genuine policy change.
Treat exit 0 as PASS, exit 1 as REVIEW_REQUIRED, exit 2 as FAILED, and exit 3 as a usage or environment failure. Exits 1 and 2 still produce receipts; inspect them instead of reporting a generic shell failure.
Describe a valid signature as post-generation integrity evidence. Do not call it trusted execution, proof of authorship, or automatic compliance evidence.

Set up a repository

Confirm the repository root and require a reasonably clean baseline when attribution matters.
Inspect tracked paths, task context, existing .codetruss.yml, package scripts, and the repository's normal lint, typecheck, test, or build commands.
Propose the smallest useful allow globs. Keep secrets, generated output, production infrastructure, and unrelated migrations denied when appropriate. Do not default to **/*.
Ask the developer to confirm the proposed boundary and verification commands.
Run codetruss init with the confirmed repeated --allow and --deny flags. Add confirmed verification commands to .codetruss.yml without disturbing unrelated configuration.
When running in Claude Code, run codetruss hooks install claude; when running in Codex, run codetruss hooks install codex. If the host is ambiguous, ask rather than installing both.
Run codetruss hooks doctor claude or codetruss hooks doctor codex. Remind Codex users to open /hooks and approve the exact repository hook definition when the doctor reports the manual trust step.

The CLI's hook installer is idempotent and preserves supported existing hook configuration. Do not replace it with plugin-bundled hook logic.

Review changes

Use the developer's actual task statement. Ask for it if the intended change is unclear; do not invent a permissive task after seeing the diff.
Use codetruss review --task "..." for current tracked and untracked changes. Add --staged only when the developer requests the index or a pre-commit review.
Use repository policy by default. Pass task-specific --allow, --deny, or --verify values only when the developer explicitly sets or approves them.
Read the receipt ID and explicit reasons. Use codetruss report latest --json when structured evidence is useful, then run codetruss verify latest before describing the receipt as valid.
Report the verdict, scope exceptions, sensitive surfaces, analyzer findings, verification results, evidence limitations, and receipt path. Distinguish a policy dispute from a product or shell failure.

For a wrapped agent run, preserve the exact task and policy:

codetruss run --task "<task>" --allow "<glob>" --verify "<command>" -- <agent-command>

Do not stage, commit, reset, clean, or sync as a side effect of review.

Repair and recheck

Repair the finding at its source while keeping the approved policy stable.
Re-run the same review mode and verification commands after the change.
If the developer intentionally changed a sensitive or denied surface, record that decision explicitly; do not silently reclassify it.
Use codetruss hooks status <surface> and codetruss hooks doctor <surface> for diagnosis. Use codetruss hooks uninstall <surface> only on an explicit removal request.

Keep the final response compact: verdict first, then actionable reasons, receipt ID/path, integrity result, and any decision still required from the developer.

codetruss

CodeTruss

Preserve the trust boundary