Command permissions

Magic Coder asks before running shell commands by default. This page explains when it asks, when it doesn’t, and what your choices in the prompt do.

Heads up. The persistent format Magic Coder uses to remember per-project allow/deny decisions is being reworked. While that’s in flight, the prompt UX described below is the supported interface — pick the action you want, and Magic Coder takes care of remembering it. The file/schema details that were previously documented here will return when the new format ships.

The decision flow

When Magic Coder wants to run a shell command, it walks through:

Workspace trust check. Project-level rules (allow / deny / remembered choices) are honored only when the workspace is trusted. If the workspace isn’t trusted, every command falls through to the prompt.
Built-in deny. A short list of patterns is always blocked at the agent layer regardless of trust state.
Built-in auto-allow. Some commands skip the prompt because they’re known-safe — see Auto-allowed commands.
Project-level remembered allow / deny. If the trust gate is open and a previous “approve & remember” or “deny & remember” matches this command, that decision applies.
Otherwise — prompt. Magic Coder pauses, shows you the command (and any context the agent provided), and waits for your choice.

deny always wins. An explicit deny on a command will block it even if a broader allow would have matched.

What the prompt looks like

When approval is needed, the input panel turns into a menu and the transcript shows what’s being requested:

Run shell command:
  cargo test --release
[a] approve once   [A] approve & remember   [d] deny   [D] deny & remember

(File edits and deletes use the same gate; you’ll see the unified diff or the file list above the prompt.)

Keys:

Key	Action
`↑` / `↓` (or `j` / `k`)	Move the selection
`Enter` (or `y`)	Apply the highlighted action
`a`	Jump to “approve”
`d`	Jump to “deny”
`n`	Reject this command immediately
`Esc`	Reject this command and skip to the next
`Ctrl+C`	Reject (or, on a plan-update prompt, drop into free-form feedback)

If multiple commands are queued for approval, the menu shows an “Approve all” action that runs every queued one in order.

What each choice does

Approve once — run this time only. Next time the same kind of command comes up, you’ll be asked again.
Approve & remember — run, AND record the decision so future identical commands run without asking. Choosing “remember” implicitly marks the workspace as trusted (project-level decisions only take effect on trusted workspaces).
Deny once — reject this run. The agent gets a short error and decides what to do next. It’s allowed to ask again with a different command, switch approaches, or back off.
Deny & remember — reject AND record a permanent block.

In --automagic, every prompt is auto-applied as “approve once.” Built-in deny rules are still enforced — automagic doesn’t override an explicit denial.

Auto-allowed commands

There’s exactly one rule that always skips the prompt: any command whose top-level segments all invoke git. So git status, git diff, git log --oneline -20, FOO=bar git rev-parse HEAD, and git status && git log all run without asking. git status; rm -rf / does not — the second segment isn’t a git invocation, so the chain falls back to the prompt.

Notes on the matcher:

Multi-segment commands are split on ;, &&, ||, |, &, with proper quote and escape handling.
Leading KEY=value env-assignment words are skipped before checking that the program word is git.
Subshells (`...`, $(...), <(...), >(...) ) make a command ineligible for the auto-allow — you’ll see a prompt.

There is no built-in auto-allow for ls, pwd, whoami, cat, etc. Those will still prompt the first time the agent uses them; choose “approve & remember” if you want them to run silently after that.

If you want to block specific git operations (like git push or git reset --hard) you can deny them explicitly through “deny & remember.”

Trust matters

Project-level remembered decisions apply only when the workspace is trusted. The first time you run coder in a new directory you’ll see a trust prompt; you can also pre-trust with --trust on the command line. See Workspaces & trust.

If you’re auditing an unfamiliar repo, leave the workspace untrusted — every command will prompt, every time, regardless of any decisions a previous user might have left in the project.

Tips

Approve & remember the routine commands. cargo test, npm run build, pnpm install, make lint. After the first session, the prompt should be quiet enough that it only fires on novel commands.
Use deny & remember for sharp edges. git push, git reset --hard, anything that publishes or destroys. The cost is a one-time decision; the benefit is no late-night surprise.
Stay deliberate while the format is in flux. If you’d previously been editing a settings file by hand to manage rules, hold off — the format is being reworked. Use the prompt to record decisions for now; the new mechanism will pick them up.

When the new format ships, this page will document it concretely.