Safety: approval modes, risk scoring and a second opinion
Darce runs commands on your machine, as your user, in the folder where you started it. So every command is parsed and scored before it runs, and anything risky waits for you with the reason shown.
Risk levels
Each command falls into one of four levels:
- Read-only: looking at files, listing, searching. Runs straight away.
- Changes the project: edits and builds inside your project folder.
- Reaches outside: network access, installs, unknown commands.
- Destructive:
rm -rf,sudo, force-push and similar.
When Darce asks, you answer with one key: y once, a always for this command in this project, n deny. Destructive commands can never be "always allowed".
Approval modes
Switch with Shift+Tab, /mode, or --mode on the command line.
| Mode | Read-only steps | Edits and builds in the project | Network, installs, unknown commands | Destructive (rm -rf, sudo, force-push…) |
|---|---|---|---|---|
auto (default) | run | run | ask | ask |
ask | run | ask | ask | ask |
plan | run | blocked | blocked | blocked |
full | run | run | run | run |
plan is read-only: Darce proposes changes without touching anything. full asks for nothing; use it only where you're comfortable with that.
A second look at scripts
A command like npm run x, node scripts/x.js or make y looks harmless to rules, but the script behind it could deploy, publish or write to a database. So before running one of these unasked, Darce:
- reads the real script line (for example from your
package.json), and - asks a fast classifier (TypeSafe Jev, via api.darce.dev) whether running it changes anything outside your machine, given the command, the script line and the start of the file it runs.
This check can only make Darce more careful, never less. Turn it off with "riskCheck": false in ~/.darcerc.
Effects that /undo can't reverse (deploys, migrations, seeds, releases, database clients) always ask first, and the prompt says so.
Second opinion on edits
/critic on has a model from a different vendor review every edit within seconds and flag bugs inline. Different vendor, different blind spots. Choose the reviewer with /critic on <model>.
For a broader check, /security reviews the whole project, or /security changes just your uncommitted diff, and reports exploitable issues by severity with proof and fixes.
Secrets
- Commands Darce runs don't see environment variables that look like credentials (
*_KEY,*_TOKEN,*_SECRET,DATABASE_URL…). Allow specific ones with"passEnv": ["GH_TOKEN"]in~/.darcerc. - Known secret formats are redacted from tool output before anything reaches a model.
- Your key, history and sessions are stored readable only by you.
Untrusted content
- After Darce reads a web page, commands that would normally run automatically ask first, so a malicious page can't quietly steer it.
- A repository's own
.darcerc, instruction files and skills can't change your approval mode, endpoints or keys, and your own skills take precedence over a repository's.
What leaves your machine
Files are read and edited, and commands run, locally. The prompt plus the files and output read during a task go to api.darce.dev and then to the model provider you chose via OpenRouter. The CLI is MIT licensed, so you can audit exactly what it does.
Next: Swarm and derby · All docs · Model directory · Claude Code alternative