Skip to main content

Safety Best Practices

Module: Cost & Safety | Lesson: 3 of 3 | Time: ~10 minutes

What You Will Learn​

  • How to maintain good permission hygiene
  • How to review all changes before accepting
  • How to handle sensitive data (API keys, passwords, .env files)

Prerequisites​

Why Safety Matters​

Claude Code is powerful. It can read files, write files, edit code, and run shell commands on your computer. That power is what makes it useful -- but it also means you need to be thoughtful about what you allow it to do.

This lesson covers the safety practices that protect you, your data, and your accounts. None of these practices are difficult, but all of them are important.

Always Review Permission Prompts​

When Claude wants to perform an action -- creating a file, editing code, running a command -- it shows you a permission prompt and waits for your approval. This is your most important safety net.

The rule: Read every permission prompt before approving.

Claude wants to execute: rm -rf node_modules/
Allow? (y/n)

Before pressing y, ask yourself:

  • Do I understand what this command does?
  • Is this what I asked Claude to do?
  • Could this cause any damage?
danger

A command like rm -rf deletes files permanently without sending them to the Recycle Bin. If you do not understand a command, type n to reject it and ask Claude to explain what the command does before trying again.

What to Watch For​

Pay extra attention when Claude wants to:

  • Delete files -- any command with rm, del, or Remove-Item
  • Modify system files -- anything outside your project folder
  • Run install commands -- npm install, pip install, etc. (these download code from the internet)
  • Access the network -- curl, wget, API calls
  • Modify git history -- git reset --hard, git push --force

Be Careful with Bash/Command Execution​

The Bash tool (or PowerShell command execution) is Claude's most powerful and most dangerous capability. When Claude runs a shell command, it has the same permissions as your user account on the computer.

Safe examples:

dir                          # List files (harmless)
git status                   # Check git state (harmless)
Get-Content README.md        # Read a file (harmless)

Potentially dangerous examples:

Remove-Item -Recurse -Force  # Delete files permanently
npm install some-package     # Download and run code from the internet
Invoke-WebRequest            # Access the network
Set-ExecutionPolicy          # Change system security settings
warning

If Claude proposes a command you do not recognize, reject it and ask Claude to explain what it does. There is never a reason to approve a command you do not understand.

Never Share API Keys​

Your Anthropic API key is like a password that gives access to your billing account. If someone else gets your key, they can use it to make API calls -- and you will be charged for their usage.

Rules for API keys:

  1. Never paste your API key into a chat message. Claude does not need your API key during a conversation -- it already has access.

  2. Never commit API keys to git. If your key ends up in a repository (even a private one), it could be exposed.

  3. Never share your key in screenshots, emails, or forum posts.

  4. Use environment variables to store keys, not hard-coded strings in your code:

    # Good: set as environment variable
    $env:ANTHROPIC_API_KEY = "sk-ant-..."

    # Bad: hard-coded in a script
    $apiKey = "sk-ant-..."  # Anyone who reads this file can see your key

  5. If you accidentally expose a key, rotate it immediately in your Anthropic account settings. Go to console.anthropic.com, revoke the old key, and create a new one.

danger

If you ever accidentally paste your API key into a Claude conversation, immediately go to your Anthropic account and rotate the key. Treat an exposed key like a compromised password.

Review File Edits Before Accepting​

Every time Claude proposes a file edit, take a moment to review it:

  1. Read the diff. In VS Code, this means looking at the green (added) and red (removed) lines. In the terminal, read Claude's description of changes.

  2. Check for unintended changes. Did Claude only change what you asked for? Sometimes Claude might "helpfully" modify other parts of the file that you did not ask about.

  3. Look for removed code. Make sure Claude did not delete something important while making its changes.

  4. Verify logic. If Claude changed code logic, read the new version carefully. Does it still do what you expect?

tip

If a change looks mostly right but you are unsure about one part, reject it and ask Claude to make the change without modifying the part you are unsure about. You can always re-request.

Use .gitignore for Sensitive Files​

A .gitignore file tells Git which files should not be tracked or committed. This is critical for keeping sensitive files out of your repository.

Create or update your .gitignore to include:

# Environment variables and secrets
.env
.env.local
.env.production

# API keys and credentials
credentials.json
secrets.json
*.key
*.pem

# Operating system files
Thumbs.db
.DS_Store

# Dependencies (can be reinstalled)
node_modules/
__pycache__/
warning

Adding a file to .gitignore only prevents future commits from including it. If you already committed a sensitive file, you need to remove it from git history. Ask Claude for help with this if needed, but be aware it involves rewriting git history.

Do Not Auto-Approve Everything​

Claude Code offers ways to grant broader permissions so you do not have to approve every action. While this can save time, it also reduces your safety net.

Beginner recommendation: Keep the default permission settings. Approve each action individually until you are very comfortable with what Claude does.

When you are more experienced, you might selectively trust specific tools:

Permission LevelWhen to Use
Approve each action (default)Always, for beginners
Trust Read/Grep/GlobWhen you are comfortable that reading files is safe
Trust Write/EditOnly in projects where you have git as a backup
Trust BashOnly when you fully understand the commands Claude runs
Trust everythingRarely -- only in isolated/sandboxed environments
danger

Never use "trust everything" in a project that contains sensitive data, credentials, or production code. One unexpected command could cause real damage.

Sandboxing Options​

For maximum safety, you can run Claude Code in a sandboxed environment where it cannot affect your main system:

  1. Docker containers. Run Claude Code inside a Docker container. Any file changes or commands only affect the container, not your real system.

  2. Virtual machines. Use a VM (via Hyper-V, VirtualBox, or WSL) as a disposable workspace.

  3. Separate user account. Create a Windows user account with limited permissions for Claude Code experimentation.

  4. Git as a safety net. Always work in a Git repository. If Claude makes unwanted changes, you can revert:

    git diff              # See what changed
    git checkout -- .     # Undo all uncommitted changes
tip

For beginners, Git is your best safety net. As long as you commit regularly, you can always undo any change Claude makes. This is one more reason why Module 01 emphasized setting up Git.

Safety Checklist​

Print this out or bookmark it. Before any Claude Code session, run through this mental checklist:

  • Am I in the right directory? (Check with pwd)
  • Is this project under Git version control? (Check with git status)
  • Have I committed my recent work? (So I can revert if needed)
  • Is my .gitignore set up to exclude sensitive files?
  • Am I prepared to read each permission prompt before approving?

Try It Yourself​

  1. Permission awareness. Start a Claude Code session and ask Claude to create a file. When the permission prompt appears, read it carefully before approving. Then ask Claude to run a PowerShell command. Again, read the prompt. Practice the habit of pausing before pressing y.

  2. Check your .gitignore. Navigate to one of your project folders. Does it have a .gitignore file? If not, ask Claude to create one with sensible defaults for your project type.

  3. Sensitive file check. Run git status in your project. Look for any files that might contain secrets (.env, credentials.json, etc.). If they are tracked by git, ask Claude to help you remove them from tracking and add them to .gitignore.

  4. Reject practice. Ask Claude to make a change to a file, but when the diff appears, reject it on purpose. Then ask Claude to try again with different instructions. Get comfortable saying "no" -- it is an important skill.

  5. Recovery practice. Make sure you have a clean git commit. Then ask Claude to make a change to a file and accept it. Now undo the change using:

    git checkout -- .

    Verify the file is restored. This proves that Git protects you from unwanted changes.

What You Learned​

  • Always read permission prompts before approving -- this is your primary safety net
  • Be especially careful with Bash/command execution -- reject anything you do not understand
  • Never share API keys in chat, code, or screenshots; use environment variables instead
  • Review every file edit in the diff view before accepting
  • Use .gitignore to keep sensitive files out of version control
  • Do not auto-approve everything -- start with default permissions and expand gradually
  • Git is your best safety net -- commit regularly so you can always revert unwanted changes
  • For maximum isolation, use Docker containers or VMs as sandboxed environments
Help Us Improve

How was this lesson? Take 2 minutes to share your feedback — it helps us make the tutorials better for everyone.

Give Feedback →

Next Up​

Next: Capstone: Cost-Conscious Project