Use Claude Code Safely

Using Claude Code Safely

Claude Code is powerful. It can read files, write files, delete files, and run commands on your computer. That's what makes it useful — and what makes it worth understanding the safety model before you get too deep.

This isn't a scare piece. Claude Code has good guardrails built in. But you should know what they are, when to trust them, and when to be careful.

How permissions work

Claude Code asks permission before doing anything that changes your files. Every. Single. Time.

When Claude wants to create, modify, or delete a file, you'll see something like:

Claude wants to:
• Create cleaned_data.csv
• Modify summary.md

Allow? [y/n]

Your options:

• y — Yes, allow this specific action
• n — No, don't do it

This permission system is your seatbelt. Claude can't silently delete your files or overwrite your work. You approve every change.

Auto-accept mode (Shift+Tab)

Typing "y" fifty times gets old. That's why auto-accept mode exists.

Press Shift+Tab to toggle auto-accept on. Claude will make file edits without asking permission. Press Shift+Tab again to turn it off and go back to asking.

You'll see an indicator in your prompt when auto-accept is active.

Auto-accept is fine when:

• You're working in a dedicated project folder
• You've backed up your input files
• The task is straightforward (clean this CSV, generate this report)
• You trust the instructions you wrote

Auto-accept is risky when:

• You're in a folder with files you care about (like your home directory)
• You're running a new, untested workflow
• The task involves deleting or moving files
• You're not sure what Claude is about to do

Rule of thumb: Keep auto-accept off until you trust what's happening. Toggle it on once you've seen the pattern and it's doing what you expect.

Never run Claude Code from the wrong directory

Where you run Claude matters. Claude can see and modify files in your current directory and subdirectories.

Dangerous:

cd ~
claude

Now Claude has access to your entire home folder. Documents, downloads, SSH keys, everything.

Safe:

cd ~/my-project/sales-reports
claude

Now Claude only sees files in that specific project folder.

Before you start any Claude session, ask: "If Claude went rogue right now, what could it mess up?" If the answer is "a lot," you're in the wrong directory.

Work on copies, not originals

Never point Claude at your only copy of important data.

Bad:

Read contracts.csv and clean it up. Save the result as contracts.csv.

If Claude misunderstands "clean it up," your original data is gone.

Good:

Read contracts.csv and clean it up. Save the result as contracts_cleaned.csv.

Now you have both versions. Check the output. If it's right, replace the original manually. If it's wrong, you've lost nothing.

For critical work: copy input files to your project's /input/ folder before processing. Keep originals somewhere else entirely.

What Claude can (and can't) see

When you run claude in a directory, it can:

• Read any file in that directory and subdirectories
• See file names, folder structure, and contents
• Access files you reference by path (even outside the directory, if you give a path)

It cannot:

• Access files you don't point it to
• Read your browser history, emails, or other applications
• Connect to the internet or external services (unless you explicitly set up integrations)
• Remember things between sessions (each run starts fresh)

Claude's "vision" is limited to the files you show it. But be aware: if your project folder contains a file with passwords or API keys, Claude can read it. Keep sensitive files out of your working directories.

When to say no

The "n" option exists for a reason. Use it when:

• Claude wants to modify a file you didn't expect
• The action list includes deleting files you care about
• You see something that doesn't match your instructions
• You're not sure what's about to happen

Saying "n" doesn't end the session. It just blocks that specific action. Claude will continue with the next step, or you can give it different instructions.

Recovering from mistakes

If something goes wrong:

You approved a bad change:

• Check if the file was backed up (Time Machine, Git, cloud backup)
• On Mac: look in Trash (Claude's deletes often go there)
• If you used Git: git checkout -- filename to restore

Claude overwrote a file you needed:

• If you followed the "save as new file" pattern, the original should still exist
• Check /archive/ or /backup/ if you set up that folder structure

You're not sure what changed:

• Next time, use Git. Run git init in your project folder, commit before running Claude, and you can always diff what changed.

The safest workflow

Here's the pattern that keeps you out of trouble:

1. Create a dedicated project folder
2. Copy input files there (don't move originals)
3. Initialize Git: git init && git add -A && git commit -m "initial"
4. cd into that folder before running claude
5. Write instructions that output to new files, not overwrite inputs
6. Keep auto-accept off for the first few runs, toggle it on (Shift+Tab) once you trust it
7. Commit after successful runs

This gives you:

• Isolation (Claude only touches this folder)
• Backups (originals are elsewhere)
• History (Git shows exactly what changed)
• Recoverability (roll back any mistake)

What you lose vs. what you risk

Real talk: these precautions add friction. You might skip them for quick tasks. That's fine — most Claude Code work is low-stakes.

But for anything involving:

• Financial data
• Customer information
• Legal documents
• Anything you can't recreate

...take the two minutes to set up safely. The worst Claude Code mistake isn't a wrong analysis — it's deleting something you needed.

Next up

Even with safety covered, things sometimes go wrong in other ways. Claude misunderstands an instruction, produces weird output, or gets stuck. In the next lesson, you'll learn how to debug and troubleshoot when your automations don't work as expected.