What guardrails are in Paqad
A guardrail is an automatic stop: a check that refuses an action until a condition is met. In Paqad, guardrails are hooks, small scripts that your AI tool runs at set moments, such as just before it edits a file or when it finishes a turn. A script decides whether to allow or block, so the AI cannot talk its way past it. How much Paqad can stop therefore depends on which hooks your AI tool offers and whether they are configured.
What each AI tool supports
| AI tool | Before an edit | At the end of a turn |
|---|---|---|
| Claude Code | Can block | Runs verification and shows a verdict |
| Codex CLI | Can block | Runs verification and shows a verdict |
| Gemini CLI | No hook | Records evidence silently, does not block |
| Cursor, Windsurf, Continue, GitHub Copilot, Junie, Aider, Antigravity, JetBrains AI Assistant | No hook | No hook |
On tools without hooks, Paqad's rules are instructions in the entry file. The AI is asked to follow them, but nothing enforces them. See Adapters overview.
The stops before an edit
On Claude Code these run before the Edit, Write and NotebookEdit tools; on Codex CLI, before apply_patch.
- Entry gate. Blocks code edits until the agent has loaded its entry file and Paqad's core instructions for this session.
- Decision pause gate. Blocks code edits while a decision is waiting for a human answer in
.paqad/decisions/pending/. You see waiting decisions withpaqad-ai decision listand answer one withpaqad-ai decision resolve <id> <option>. - Capability gate. Runs Paqad's registered checks, such as whether the required feature development stages were recorded (
stages_mode, defaultstrict), whether the applicable rules were loaded before the first code edit, and your rules that have been turned into scripts (rule_compliance, defaultwarn). A check set towarnreports but does not block.
The check at the end of a turn
On Claude Code and Codex CLI, a completion hook runs Paqad's verification against the actual state of the repository and reports one trust verdict. If its own setup is broken, it lets the turn finish rather than trapping the agent. See Health checks for keeping the installation sound.
What these guardrails do not stop
- Shell commands. The hooks watch file-editing tools only. A command run through the AI tool's shell, such as
rm -rf,git push --forceor a SQLDROP TABLE, is not checked by Paqad. The package contains ablock-destructive.shscript for this, but paqad-ai 1.91.1 does not register it with any AI tool. Use your AI tool's own permission settings to control shell commands. - Secrets in commits. There is no commit-time secret block. The security review and
paqad-ai health runsearch for secrets when you run them. - Database migrations. No gate requires a database review before a migration.
- Security findings. Findings from the security review are reported, not enforced. See The security review workflow.
.paqad/.config contains escalation settings such as escalate_destructive_operations (default block), escalate_risky_migrations, escalate_security_findings, escalate_db_row_threshold, require_adversarial_review and require_db_review_for_migrations. In 1.91.1 no running code reads them, so changing them has no effect. Run paqad-ai config effective to see, for every setting, which part of Paqad reads it.
Turning guardrails off, and overrides
paqad-ai disableswitches Paqad off for the project, andpaqad-ai enableswitches it back on. Setting the environment variablePAQAD_DISABLED=1switches it off for a single run without editing any files. While Paqad is off, every hook allows everything.- There is no per-task override command. Older documentation showed
paqad-ai task --override-guardrail; that command does not exist. To get past a stop, meet its condition: answer the pending decision, record the missing stage, or fix the rule violation. - Loosening a check, for example setting
stages_modetowarnin.paqad/.config, is a team decision. The file is a local setting, so agree it with your team rather than changing it quietly.