How to Use AI Safely with Bash Commands

AI assistants are great at generating Bash. They’re also great at confidently generating Bash that will delete your home directory, leak your AWS keys, or wedge a production server. Here’s a practical safety framework that has held up over a year of daily use.

The five Bash safety rules for AI-generated commands

1. Never paste straight into a root shell

Read every command before running it. Yes, even the one-liners. Especially the one-liners. The model is right ~95% of the time, which is exactly the wrong rate to build the habit of trusting it.

2. Bake safety into the prompt

Our Bash Script Code Review Prompt and Linux Server Troubleshooting Prompt both include explicit safety constraints:

Label any command that is destructive, requires sudo, or affects running services as DANGEROUS and explain the blast radius.

This works. Models follow instructions reliably when you set them up front.

3. Always ask for `--dry-run` or check-mode first

For any command with state-changing potential, ask: “Show me the dry-run version of this command first. What output should I expect if it’s safe to run?”

For rsync, ansible-playbook, terraform, kubectl, the dry-run/check flag is your friend.

4. Watch for these dangerous patterns

The model has occasionally generated each of these. None should ever appear in your production scripts:

rm -rf $VAR/something where $VAR could be empty (you’d rm -rf /something)
find / -name X -delete without -maxdepth or -mount
chmod -R 777 (almost never the right answer)
eval "$user_input"
curl ... | bash for anything you didn’t audit
sed -i without a backup or version-control commit first
Anything that touches ~/.ssh, ~/.aws, or /etc/sudoers

5. Test in a container or VM before the real host

For any non-trivial script, run it in a throwaway environment first:

# Quick Ubuntu sandbox
docker run -it --rm -v "$PWD:/work" -w /work ubuntu:22.04 bash

# Quick Rocky/RHEL sandbox
docker run -it --rm -v "$PWD:/work" -w /work rockylinux:9 bash

If the script touches systemd or kernel features, use a real VM (multipass, lima, vagrant, libvirt).

The “ask before destructive” prompt pattern

Add this to any system prompt that involves command generation:

Before suggesting any destructive command (anything that deletes files, drops tables, stops services, modifies network configuration, or affects running workloads), pause and ask me to confirm the intent. List the exact effect, the blast radius, and what an “undo” would look like. Only then provide the command.

It changes the assistant’s behavior significantly.

When the model is confidently wrong

A few real examples from production use:

Suggested nova reset-state to “fix” a stuck VM. This masks the underlying problem; the actual fix was a Neutron port-binding issue.
Suggested iptables -F to “reset firewall rules.” On a remote server, this would have locked us out.
Suggested find / -name "*.log" -mtime +30 -delete to free disk. This would have deleted active service logs Prometheus was scraping.

In each case, asking “what could go wrong with that command?” before running it would have caught the issue.

Build the habit

Every time you copy a command from an AI tool, run it through this checklist mentally:

What does it do?
What does it touch?
What if a variable is empty?
Is there a dry-run flag?
Have I tested it in a sandbox?

Five seconds of friction prevents most disasters.