Reviewing Changes and Protecting Files | Claude Code Guide

Claude Code is powerful. It reads your files, creates new ones, runs scripts, connects to databases. That power is exactly why it's useful. It's also why you should treat it like a very capable employee who still needs supervision. Trust Claude. But verify the important stuff. ## Review Before Approving Claude asks permission before making changes. This is your safety net. Use it. When Claude says "I'll modify these three files," read what it's changing. For small changes (fixing a color, adjusting spacing), a quick glance is enough. For big changes (restructuring files, deleting content, modifying critical parts), read carefully. If you're not sure what a change does, ask before approving: ```text Before I approve this, explain what each change does and why you're making it. ``` Claude will break it down in plain English. If the explanation makes sense, approve. If something seems off, decline and ask for a different approach. ## Protect Sensitive Information Some files should never be shared, published, or modified carelessly: - **Passwords and secrets:** Database credentials, API keys, login details - **Personal data:** Customer information, financial records, private documents - **Configuration files:** Server settings, environment files (often called `.env`) Put this in your CLAUDE.md: ```markdown ## Off-Limits Files - Never modify or display the contents of .env files - Never include passwords, API keys, or credentials in any file - Never commit .env files to version control ``` Claude follows these rules. But you should also check. If Claude creates a configuration file, glance at it to make sure no sensitive data is hardcoded. ## Backups Are Your Safety Net We covered backups in Module 4. Here's the habit version: **save a snapshot before every big change.** ```text Create a backup zip before I make any major changes. ``` This takes seconds. If the change goes badly, you have a save point. Without it, you're manually undoing changes or, worse, trying to remember what things looked like before. How often to back up: - Before any major change (redesign, restructuring, new feature) - After completing a section that works well - At the end of every work session - When you think "I'd be upset if I lost this" There's no cost to backing up too often. There's a real cost to backing up too rarely. ## Long Conversations Drift After many exchanges, Claude's responses can become less accurate. It's juggling context from everything you've discussed. Early instructions might get diluted by later ones. Things you said ten prompts ago might be partially forgotten. **Signs a conversation has drifted:** - Claude makes mistakes it didn't make earlier - It contradicts instructions you gave in the same session - Responses feel less focused or relevant - Claude asks you about something you already explained **The fix is simple:** start a new session. Type `/exit`, then `claude`. Fresh start. CLAUDE.md gets re-read. Your files are re-scanned. Clean slate. I start new sessions multiple times a day. One task per session is a good default. It's not inefficient. It's disciplined. ## The "Explain First" Habit Before making any change you're unsure about, ask Claude to explain its plan: ```text I want to reorganize the CSS files. Before doing anything, explain what you'd change, which files you'd modify, and what the result would look like. ``` Review the plan. Give feedback. Only then say "go ahead." This is Plan Mode (Shift + Tab) formalized as a habit. For small, safe changes, you don't need this. For anything that touches multiple files or changes something structural, the explain-first habit prevents surprises. ## Don't Publish Sensitive Data When you put your site online, make sure your project folder doesn't contain: - Passwords or API keys - Personal documents unrelated to the website - Planning documents with client information - The `.claude` folder (your commands and rules are for Claude, not the public) Ask Claude to check: ```text Review the project and list any files that might contain sensitive information or shouldn't be published publicly. ``` Better to catch it before deploying than after. ## When Claude Is Wrong Claude will occasionally be wrong. It might: - Tell you something works when it doesn't - Give advice that's outdated or incorrect - Suggest a fix that introduces a new problem - Miss something obvious This doesn't mean Claude is broken. It means it's an AI, not an oracle. When something doesn't seem right: 1. Test it yourself (open the page, click the button, check the file) 2. If it doesn't work, tell Claude: "That didn't work. Here's what happened." 3. If Claude keeps getting something wrong, try a completely fresh session with a different approach ## How I Stay Safe My CLAUDE.md has a rule: "Never commit `.env` files." Claude follows it. But I still check before publishing. I also save snapshots before every structural change. Costs me ten seconds. Has saved me hours. The biggest safety lesson I've learned: specificity prevents accidents. "Clean up the footer" is dangerous. "Remove the empty gap between the links and the copyright text in the footer" is safe. The more precisely you describe what you want, the less room there is for unwanted surprises. Trust Claude. It's remarkably capable. But keep the verification habit. The combination of AI capability and human judgment is what makes Claude Code powerful. Remove either one and it's less effective. > Next up: automating the boring stuff. Now that you know the basics, let's make Claude do repetitive tasks for you.

Staying Safe and Keeping Claude on Track

Review Before Approving

Sign In to Unlock

Check Your Email