Claude Code guardrails: how to prevent destructive actions and protect your codebase

Claude Code is an autonomous coding agent. It reads your project, writes code, runs commands, and makes git commits. Most of the time, it does exactly what you want. But the times it does not can cost you an afternoon.

A force-push to main overwrites your team's work. A dropped database table means restoring from backup. A deleted file that was not in git is gone. These are not theoretical scenarios. They are the kind of things that happen when a powerful tool operates without explicit boundaries.

Guardrails solve this. They are specific rules in your CLAUDE.md that tell Claude what actions to never take, and what to do instead.

Why guardrails matter more than you think

Claude Code has access to your terminal. It can run any command your user account can run. It uses this access responsibly, but "responsibly" is based on general training, not your specific project's requirements.

In a typical project, Claude might:

• Run git push --force to resolve a diverged branch
• Delete a config file it thinks is unused
• Run git reset --hard to clean up a messy working directory
• Drop and recreate a database table to fix a schema issue
• Skip pre-commit hooks with --no-verify because a linter is complaining

Each of these makes sense in some context. None of them are what you want as default behavior. Guardrails turn these from "Claude's judgment call" into "explicitly prohibited."

The essential guardrails every project needs

1. Git safety

# Git Guardrails
- Never force-push (git push --force or --force-with-lease) to main or master
- Never run git reset --hard without explicit confirmation
- Never skip hooks with --no-verify. If a hook fails, fix the issue.
- Never amend commits that have been pushed to remote
- Always create new commits instead of amending when unsure
- Do not push to remote unless explicitly asked to

The force-push rule is the most important single guardrail you can set. A force-push to a shared branch can overwrite days of work from multiple team members. Claude might reach for it when a rebase creates conflicts or when local and remote branches diverge.

The --no-verify rule matters because Claude sometimes tries to bypass failing pre-commit hooks instead of fixing the underlying issue. The hook exists for a reason. Skipping it hides the problem.

2. File safety

# File Safety
- Never delete files with rm. Move to .trash/ instead: mv file .trash/
- Never overwrite files without reading them first
- Do not delete files that are not tracked by git without confirmation
- Preserve intermediate outputs before retrying failed operations

The .trash/ pattern is more useful than it sounds. Claude occasionally decides a file is unused and removes it. If the file was in git, you can recover it. If it was not (a local config, an untracked data file), it is gone. Moving to .trash/ instead of deleting gives you a safety net.

3. Database safety

# Database Guardrails
- Never drop tables or databases without explicit confirmation
- Never modify migration files after they have been applied
- Never run destructive queries (DELETE, TRUNCATE, DROP) on production data
- Always create a new migration for schema changes, never edit existing ones
- Back up data before running migrations on non-empty tables

Database guardrails are critical for any project with persistent data. Claude will sometimes propose dropping and recreating a table as the simplest fix for a schema mismatch. That "fix" destroys your data.

4. Security guardrails

# Security
- Never commit .env files, API keys, tokens, or credentials
- Never hardcode secrets in source code
- Never log sensitive data (passwords, tokens, PII)
- Never use subprocess with shell=True
- Never disable SSL verification
- Do not add third-party dependencies without checking their maintenance status

Security guardrails prevent the kind of mistakes that create vulnerabilities. Claude generally avoids these patterns, but in complex debugging sessions it might temporarily hardcode a value or disable a security check "just to test." The guardrail prevents the temporary fix from becoming permanent.

5. Dependency and infrastructure guardrails

# Dependencies & Infrastructure
- Do not add new dependencies without asking first
- Do not upgrade major versions of existing dependencies without confirmation
- Do not modify CI/CD pipeline configuration without confirmation
- Do not change build tool configuration (webpack, vite, etc.) without confirmation
- Do not modify Docker or container configuration without confirmation

These guardrails prevent scope creep. Claude might add a utility library to save three lines of code, or upgrade a dependency to fix a deprecation warning. Both are reasonable actions that can break your build in unexpected ways.

Writing effective guardrails

Be specific, not vague

Bad: "Be careful with the database." Claude does not know what "careful" means in your context.

Good: "Never run DELETE without a WHERE clause. Never drop tables without confirmation." Claude knows exactly what to avoid.

Include the safe alternative

Bad: "Never delete files." This prevents Claude from doing something it sometimes needs to do.

Good: "Never delete files with rm. Move to .trash/ instead." Claude can still remove files from the working directory, just safely.

Focus on irreversible actions

Guardrails are most valuable for actions that are hard to undo. Reformatting code is easy to revert. Force-pushing a branch is not. Focus your guardrails on the high-consequence actions.

Do not over-restrict

Twenty guardrails is a lot. If you list every possible bad action, Claude spends more time checking restrictions than writing code. Focus on the 5-10 rules that prevent the biggest disasters. Everything else is handled by good architecture guidance and conventions.

Project-specific guardrails

Beyond the universal rules, every project has its own danger zones. Think about:

• What directory must never be modified? Production configs, deployed manifests, vendor directories.
• What commands must never run in production? Seed scripts, test data generators, migration rollbacks.
• What patterns must never be introduced? Global state, circular imports, God classes.
• What third-party systems must not be called? Payment processors, email services, external APIs in test environments.

These are the guardrails that prevent the mistakes unique to your project. The ones you learned about the hard way. Write them down so Claude never has to learn the same lesson.

Testing your guardrails

Guardrails only work if Claude reads them. The ContextKit Analyzer checks whether your CLAUDE.md has a guardrails section and evaluates its quality. It scores you on specificity (concrete rules vs vague advice) and coverage (the major risk categories).

If your guardrails score is below 2 out of 2, the analyzer tells you exactly what is missing: "No git safety rules detected" or "No mention of file deletion policy." These are the gaps where mistakes happen.

To add guardrails to an existing CLAUDE.md, you can use the ContextKit Generator to create a section template. Pick your stack, and it generates guardrails appropriate for your framework and tools.

For team projects, run npx contextkit score in CI. If someone removes a guardrail in a pull request, the score drops and the pipeline flags it. Guardrails are too important to remove by accident.