Lesson 4.3

Dangerous Commands to Watch For

8 minutes

This is the security lesson of the course. Everything you’ve learned so far has been about understanding what commands do. This lesson is about knowing when to stop and think before running one.

Your AI coding assistant is not trying to harm you. But it doesn’t always consider the consequences of destructive commands. It’s focused on solving your problem, and sometimes the fastest solution involves a command that could cause real damage if something goes wrong.

Red Flag 1: rm -rf / or rm -rf ~

You saw this in the last lesson. These commands attempt to delete everything:

rm -rf /       # Everything on the entire system
rm -rf ~       # Everything in your home directory
rm -rf *       # Everything in the current directory

An AI tool would never intentionally suggest rm -rf /. But it might suggest something like rm -rf $VARIABLE/ where $VARIABLE is empty – and an empty variable turns that into rm -rf /.

The Rule
Any time you see rm -rf in a suggestion, stop and read the full command carefully. Make sure you understand exactly what path it targets before you approve it.

Red Flag 2: find … -delete

The find command is incredibly useful for locating files. But it has a -delete flag that will delete every file it finds – and find can match thousands of files at once.

Here’s the dangerous version:

find ~/projects -name "*.log" -delete

This finds every .log file in your projects directory and deletes them all. Instantly. No confirmation.

Here’s the safe approach – always preview first:

Try it now:

find ~/projects -name "*.log" -type f

This runs the same search but without -delete. It just shows you what would be affected. Look at the output. Are those the files you actually want to remove? Only after confirming should you add -delete.

The Two-Step Rule for find -delete
Step 1: Run find without -delete to see what matches.
Step 2: Only add -delete after you've reviewed the list and confirmed every file should go.

Red Flag 3: chmod 777

You learned about file permissions back in Module 2 when reading ls -l output. The command chmod changes those permissions, and 777 is the most permissive setting possible:

chmod 777 file.txt

What 777 means: everyone – the file owner, the group, and every other user on the system – gets full read, write, and execute permissions.

Try it now:

ls -l ~/projects/my-app/README.md
chmod 777 ~/projects/my-app/README.md
ls -l ~/projects/my-app/README.md

Look at the permission string before and after. It should change to -rwxrwxrwx – completely open to everyone.

Why chmod 777 Is a Security Risk
On a server or shared system, chmod 777 means any user can read, modify, or execute that file. For scripts, this means anyone could change the code and it would run with those changes. For config files, it means anyone can read your settings. AI tools sometimes suggest chmod 777 as a quick fix for "Permission denied" errors, but it's almost always the wrong solution.

When an AI tool suggests chmod 777 to fix a permission error, a better approach is usually:

  • chmod 755 for directories or executable scripts (owner can write, others can read/execute)
  • chmod 644 for regular files (owner can write, others can only read)

Red Flag 4: Exposing Secrets in .env Files

This one is more subtle. It’s not a destructive command, but it’s a security concern. The .env file in a project usually contains secrets: API keys, database passwords, tokens.

Try it now:

cat ~/projects/my-app/.env

Look at the output. You’ll see lines like API_KEY=... and DATABASE_URL=.... These are sensitive values.

The risk here is not about the cat command itself. It’s about what happens when AI tools read these files:

  • If your AI tool displays .env contents in a shared session, others might see your secrets
  • If it copies .env data into code or logs, those secrets could end up in version control
  • If it suggests committing .env to git, your secrets become public
Protect Your .env Files
Always make sure .env is listed in your .gitignore. If an AI tool suggests committing it or displays its contents, be aware that those are real secrets that should stay private.

The General Rule

Here’s the pattern to watch for. If an AI tool suggests a command that includes any of these, stop and make sure you understand it first:

Flag/Pattern What it does Risk level
-rf or --force Forces the action, skips confirmations High – no chance to cancel
-delete Deletes matching files High – can affect thousands of files
chmod 777 Gives everyone all permissions Medium – security exposure
> filename Overwrites a file completely Medium – replaces contents
sudo Runs as administrator High – bypasses all protections

Your AI assistant is a powerful tool. But it optimizes for solving problems, not for caution. You are the human in the loop. When you see these red flags, take five seconds to read the full command, understand what it targets, and decide whether you’re comfortable with the consequences.

Your Job as the Human in the Loop
Your AI assistant isn't trying to harm you, but it doesn't always consider the consequences of destructive commands. Before approving any command with -rf, --force, -delete, chmod 777, or sudo, stop and understand what it does. You are the last line of defense.

Practice

Try these in the terminal to build your instincts:

  1. find ~/projects -name "*.log" -type f – preview what a mass delete would target (safe to run)
  2. chmod 777 ~/projects/my-app/README.md then ls -l ~/projects/my-app/README.md – see how permissions change
  3. cat ~/projects/my-app/.env – read the safety note about exposed secrets
BlueBox Terminal