ReviewQueue vs blocklists only
Blocklists scale instant prevention for known-bad patterns but cannot judge novel commands in context. ReviewQueue adds a human checkpoint for risky or ambiguous actions — at the cost of reviewer latency and wrapper discipline.
Blocklists only (e.g. DestructGuard), ReviewQueue
Blocklists only (e.g. DestructGuard)
DestructGuard and similar blocklists match destructive shell, SQL, and git patterns at execution time with approve-or-abort prompts and JSONL audit logs. They excel when the harm is recognizable before it runs and when teams want zero human delay for obvious blocks. They struggle when agents invent new paths — refactors that touch prod configs, unfamiliar deploy flags, or repo-specific scripts blocklists have never seen.
ReviewQueue
ReviewQueue classifies risk, queues the command with cwd and git diff context, and waits for explicit human approve or reject before running anything. Reviewers see enough context to allow a legitimate `git push` while denying a reckless one. Tradeoffs: commands must go through `reviewqueue exec --`, approval adds latency to agent loops, and agents with raw shell access can bypass the wrapper. JSONL audit logs document who approved what.
Recommendation
Blocklists scale instant prevention for known-bad patterns but cannot judge novel commands in context. ReviewQueue adds a human checkpoint for risky or ambiguous actions — at the cost of reviewer latency and wrapper discipline.
When to combine
Many teams run DestructGuard (or similar blocklists) for instant blocks on known patterns, then route everything else — or high-context git and deploy commands — through ReviewQueue for a human yes/no. JSONL audit logs from both tools feed IncidentScribe postmortems when incidents still occur.