Should I use Jev to check shell command safety?
Verdict for the sample idea
Run it on
Jev
A bounded judgment over text, made many times. A System One model fits.
Sample idea
Before our coding agent runs a shell command, classify the command as read-only, reversible or irreversible. Read-only commands run without asking. Irreversible commands always ask the user. Hundreds of commands per session.
Explanation
Permission prompts on every command make an agent useless. Static allowlists are too coarse. git can be harmless or destructive, and the difference is in the arguments. A fast judgment on each command fits between the two. Several public Claude Code hooks already do this with Jev.
Shape it as a Choice with three options and write each as a situation. Read-only means it changes no file, no remote state and no configuration. Reversible means the change can be undone with one known command. Irreversible means it deletes, overwrites, force-pushes, sends or publishes. Send the command, the working directory and the last few commands as state. rm -rf build is a different thing in a project folder and in the home folder.
The policy is asymmetric, and it lives in code. Auto-approve only read-only at high confidence. Irreversible always asks. Everything unclear asks. A wrong "ask" costs a second. A wrong "approve" can cost a repository.
The common trap is to make Jev the only guard. This input is hostile by nature. A file that the agent just read can contain text that tries to steer the next answer, and TypeSafe lists adversarial content as a known weakness. Run a deterministic deny-list before Jev, with patterns for rm -rf /, credential files, curl | sh and force pushes to main. Jev reduces prompts. It does not replace the sandbox.
Start in shadow mode. Log Jev's answer next to what the user decided for two weeks, and read the disagreements before Jev approves anything alone.
Related tasks
Verdict produced by Jev on 2026-09-19, rubric version 2. Text written by a person. How the tool works: the report.