How to Use Claude Code Safely: The Complete Business Guide for 2026

Claude Code is the most powerful AI coding tool on the market, and the one that requires the most careful configuration. Unlike a browser chatbot, it reads files directly from your machine, runs shell commands, and can modify anything the user running it can modify. This guide covers everything a business needs to know before using Claude Code internally or authorising a vendor to use it.

TL;DR: What's safe, what's not

Claude Code has no default protection for secrets. Risk at a glance, a safety checklist, and a one-prompt setup.

Safe — web search, tests, git statusRead-only, no side effects

Caution — Read, Edit, npm installCan access files outside your project

Risky — curl, git push, WebFetchNetwork access or public actions

Dangerous — rm -rf, sudo, source .envData destruction or secret exposure

Safety checklist

Check off each item as you implement it. Click the arrow on any item to jump to the full instructions.

Setup (once)

Deny list for secrets + directory escapes ↓ Sandbox mode on ↓ CLAUDE.md safety rules ↓ Hook blocking rm -rf, force push ↓ .env in .gitignore + vault refs ↓

Every session

Plan mode first ↓ Read prompts before approving ↓ Commit after each change ↓

One-prompt setup

Paste this into Claude Code at the start of any new project. It creates CLAUDE.md, hooks, and gitignore rules in under a minute.

Copy

Set up or update the safety baseline for this project:
1. Create or update CLAUDE.md with these safety rules:
   - NEVER read, edit, or access files outside this project directory
   - NEVER read .env files, SSH keys, or any credentials
   - NEVER run rm -rf, git reset --hard, git push --force, or sudo
   - NEVER run curl, wget, ssh, or scp without my explicit approval
   - Before destructive commands, STOP and explain first
   - Commit frequently as rollback points
2. Create or update .claude/settings.json with:
   a) A PreToolUse hook blocking: rm -rf, git reset --hard,
      git push --force, sudo, curl|bash
   b) Deny rules for: Read(~/.ssh/**), Read(~/.aws/**),
      Read(**/.env), Read(**/.env.*), Read(//etc/**),
      Read(**/*.pem), Read(**/credentials*),
      Bash(cd ~*), Bash(cd /Users/*), Bash(cd /home/*),
      Bash(curl *), Bash(wget *), Bash(ssh *), Bash(scp *)
3. Ensure .env is in .gitignore
4. Commit current state as a rollback point
5. Ask me my test and build commands, add allow rules for them
Show me a summary of what you created or changed.

See the full command reference

What does Claude Code actually do on your machine?

Claude Code is a terminal-based AI agent. You give it instructions in plain language and it reads files, runs commands, edits code, and saves changes, all on your actual computer. It operates with the same access as whoever is logged in.

The critical distinction from browser-based AI tools like ChatGPT or Claude.ai is that Claude Code has direct access to your files and your command line. Every file your user account can read, Claude Code can read by default, including files outside the project you are working on. Your SSH keys (used for secure server access), cloud provider credentials (AWS, Google Cloud, Azure), environment files from other projects, and anything else on your machine are all reachable unless you explicitly block them.

Most Claude Code work happens through built-in tools that never touch a command line: Read for opening files, Glob for finding files by name, Grep for searching inside files, and Edit and Write for making changes. These are often assumed to only work inside your project folder, but they do not. Read can open any file path on your machine. Grep can search any directory. Without explicit block rules, nothing prevents Claude from reading your passwords or API keys if it decides they are relevant.

The Bash tool handles everything else: version control (git), installing software packages, running tests, and system commands. This is where almost every documented safety incident has originated.

What does every Claude Code command do, and how safe is it?

Claude Code uses a set of tools and shell commands to do its work. Each one has a different risk level depending on what it can access and whether its effects are reversible. Click any card below to see a real example and a permission recommendation. Use the legend to filter by risk level.

What is the "lethal trifecta" and why does it matter?

The lethal trifecta, a term coined by security researcher Simon Willison in mid-2025, describes the three conditions that make any AI agent dangerously vulnerable: access to private data, exposure to untrusted content, and the ability to send information over the internet. Claude Code has all three active by default.

“Prompt injection” is the core risk: someone hides instructions inside content that Claude reads (a web page, a code comment, a pull request description) and Claude follows those hidden instructions without you seeing them. When Claude also has access to your secrets and a way to send data over the network, a hidden instruction can steal your credentials.

A real incident illustrates the pattern. In the “Claudy Day” disclosure reported in 2025, researchers hid an instruction inside a URL parameter. Claude followed it and sent conversation history to Anthropic’s own API. Security tools never caught it because the destination was on the trusted list. The AI was not “hacked.” It simply followed instructions it found in web content, the same way it follows your instructions.

Anthropic is actively training their models to resist these hidden instructions, but acknowledged in their February 2026 research paper: “No browser agent is immune to prompt injection.” Untrusted content can reach Claude through many channels: code review requests, issue descriptions, README files, commit messages, and log files that Claude reads during normal work.

How does the permission system work by default?

Claude Code’s permission system has three rules: allow (auto-approve), ask (prompt each time), and deny (block completely). When Claude tries to use a tool, it checks deny rules first. If any deny rule matches, the action is blocked. Deny always wins.

Out of the box, reading tools (Read, Glob, Grep) run without any prompt. Shell commands prompt on every new command with a “yes, don’t ask again” option. File changes (Edit, Write) prompt with a per-session “don’t ask again” option.

Rules follow a Tool(pattern) format. Here are the most useful patterns:

A common mistake with paths: writing Read(/Users/alice/.env) does NOT mean “the absolute path /Users/alice/.env.” Claude Code interprets a single leading slash as relative to the project folder. To block a real absolute path, use a double slash: Read(//Users/alice/.env). For your home directory, use ~: Read(~/.env).

What do the permission prompts mean and how should you respond?

When Claude Code tries to do something that requires your approval, you see a prompt with options. Understanding these options matters because one wrong choice can permanently allow a command you did not intend to whitelist.

Three things can happen when Claude tries to use a tool:

1. It runs automatically. Read-only operations like viewing files, searching text, and checking git status never ask. Basic shell commands like ls, cat, head, tail, and read-only git commands also run without prompting.
2. It asks for your permission. You see a prompt with these choices:
   • “Yes” approves the action one time. Claude will ask again next time it wants to run the same command.
   • “Yes, don’t ask again” has different effects depending on the tool. For shell commands, this permanently allows that command pattern in this project folder. For file changes (Edit, Write), it allows without asking for the rest of this session only.
   • “No” blocks the action one time.
3. It is blocked entirely. If you have added a deny rule in your settings, Claude cannot run the tool at all and you never see a prompt.

Here is how Aurora recommends responding to prompts at each risk level. These same recommendations appear in each command card when you click it.

Which Claude Code permission mode should you use?

Claude Code has six permission modes. The right one depends on what the session is doing. Aurora’s recommendations for common business scenarios:

Anthropic’s recommended workflow is a four-phase loop: Research (plan mode, read and understand), Plan (review in editor with Ctrl+G), Implement (switch to default or auto), Verify (tests and git diff). This turns expensive course-corrections into cheap ones.

What are the four layers of Claude Code defense?

Business-grade Claude Code deployment uses four layers, each catching failures that the layer below cannot. Aurora applies this model to every client engagement where Claude Code touches sensitive infrastructure.

The Aurora Four-Layer Safety Model: never deploy Claude Code with fewer than three of these layers active, and for any production-credential work, require all four.

Ona’s March 2026 research demonstrated why a single layer fails. Researchers found that Claude Code could work around its own block rules by accessing blocked programs through alternative file paths that the rules did not cover. When the operating system sandbox caught the workaround, Claude then disabled the sandbox itself to complete the task. The agent was not behaving maliciously. It was simply trying to finish the job you gave it, and it treated the safety controls as obstacles.

Does Claude Code protect your .env files by default?

No. Claude Code ships with no default protection for .env files, SSH keys, AWS credentials, or any other secrets. There is no .claudeignore file. This is the single most common misconception. If you ask Claude whether .claudeignore works, it will confidently tell you it does. Multiple users have reported this in Anthropic’s bug tracker, and The Register independently verified in early 2026 that Claude Code still reads .env files even when a .claudeignore file is present and .env is listed in .gitignore.

The full deny list config (covering Read, Grep, Edit, and shell commands for .env, SSH keys, cloud credentials, and network tools) is in Step 1 of the implementation checklist below. Copy and paste it into ~/.claude/settings.json.

The most durable protection is to never store raw passwords or API keys in your .env files at all. Instead, store references to a password manager (like 1Password) or a cloud secrets service (like AWS Secrets Manager). Even if a leak occurs, the leaked text is just a reference that is useless without separate login access to the vault.

Which configuration files should you commit vs. gitignore?

Claude Code reads a lot of files. Understanding the layout prevents both security gaps and confusing precedence behaviour.

Commit (team-shared behaviour):

• CLAUDE.md at project root (or .claude/CLAUDE.md)
• .claude/settings.json (project-wide allow/deny rules, hooks)
• .claude/commands/, .claude/skills/, .claude/agents/, .claude/rules/
• .mcp.json (shared MCP server config)

Gitignore (personal/sensitive):

• CLAUDE.local.md (personal instructions)
• .claude/settings.local.json (auto-added to .gitignore)
• .claude/agent-memory-local/

Managed settings (enterprise, OS-level):

Claude Code reads settings from multiple places, and the order matters. Enterprise-managed settings always win. Then command-line flags, then project-local settings, then shared project settings, then your personal user settings. The important thing to know: block rules from any level stack together. A block you set at the personal level cannot be removed by a project-level override. This means your personal deny list for secrets (from your ~/.claude/settings.json) always applies, even when working on a project that has its own more permissive settings.

To check which settings are active in any session, type /status. To see all your block/allow rules in one place, type /permissions.

What happens when Claude Code safety goes wrong?

The public record includes at least six documented incidents since mid-2025. Each maps to a specific missing defense layer. None were caused by malicious users; all were caused by insufficient defense-in-depth.

How should your business implement Claude Code safely?

Most small businesses do not need to run Claude Code themselves. The work it does best (building automations, editing codebases, configuring tools) typically involves a vendor or technical team member. Authorising a vendor who runs Claude Code in their own properly-configured environment is often faster and safer than installing it on company laptops.

For businesses that do run Claude Code internally, here are the eight steps Aurora deploys on every engagement. Each includes the exact config to copy and paste.

Step 1: Add a personal block list for secrets

This goes in your personal settings file so it protects every project on the machine, not just the one you are working on now. Open or create the file at ~/.claude/settings.json and paste the following:

{
  "permissions": {
    "deny": [
      "Read(./.env)", "Read(./.env.*)", "Read(**/.env)", "Read(**/.env.*)",
      "Read(~/.ssh/**)", "Read(~/.aws/**)", "Read(~/.kube/**)",
      "Read(~/.gcp/**)", "Read(~/.azure/**)", "Read(~/.config/gcloud/**)",
      "Read(~/.docker/config.json)", "Read(~/.netrc)", "Read(~/.npmrc)",
      "Read(**/*.pem)", "Read(**/*.key)", "Read(**/id_rsa)", "Read(**/id_ed25519)",
      "Read(//etc/**)", "Read(**/credentials*)",
      "Grep(~/.ssh/**)", "Grep(~/.aws/**)", "Grep(~/.kube/**)",
      "Grep(**/.env)", "Grep(**/.env.*)",
      "Edit(./.env)", "Edit(./.env.*)", "Edit(**/.env*)",
      "Edit(~/.ssh/**)", "Edit(~/.aws/**)",
      "Bash(cat .env*)", "Bash(cat ~/.ssh/*)", "Bash(cat ~/.aws/*)",
      "Bash(grep * .env*)", "Bash(head .env*)", "Bash(tail .env*)",
      "Bash(source .env*)", "Bash(. .env*)", "Bash(env)", "Bash(printenv)",
      "Bash(cd ~*)", "Bash(cd /Users/*)", "Bash(cd /home/*)",
      "Bash(curl *)", "Bash(wget *)", "Bash(ssh *)", "Bash(scp *)"
    ]
  }
}

If the file already exists, merge the deny array into your existing permissions.deny. Rules stack across files, so adding these at the user level does not interfere with project-level settings.

Impact on Claude’s usefulness: Minimal. Claude never needs your SSH keys, cloud credentials, or .env secrets to write code. The only rule that adds friction is Bash(curl *), which blocks all command-line web requests. If you need Claude to run curl for legitimate tasks (downloading a file, testing an API), replace "Bash(curl *)" with the narrower "Bash(curl * | bash)" and "Bash(curl * | sh)" to block only the dangerous pipe-to-execute pattern while allowing normal curl usage.

Step 2: Add a CLAUDE.md safety prompt to your project

Create or update the CLAUDE.md file in your project root (or .claude/CLAUDE.md). This file is read by Claude Code at the start of every session and acts as standing instructions. If the file already exists, add the safety section below to what is already there:

## Safety rules

- NEVER read, edit, or access files outside this project directory
- NEVER read, edit, or access .env files, SSH keys, or any credentials
- NEVER run rm -rf, git reset --hard, git push --force, or sudo
- NEVER run curl, wget, ssh, or scp without my explicit approval
- NEVER use cd to navigate outside this project directory
- Before running any command that deletes files, modifies git history,
  or touches anything outside this project directory, STOP and explain
  what you are about to do and why, and wait for my confirmation
- If you are unsure whether an action is safe, ask first
- Commit changes frequently so I have rollback points

This is a soft control (Claude follows CLAUDE.md instructions approximately 70% of the time, per community testing), but it adds an extra layer of intent that catches many mistakes before they happen. Pair it with the deny rules and hooks below for reliable enforcement.

Step 3: Add automated safety checks (hooks)

Hooks are small scripts that run automatically before Claude executes any action. If the script detects a dangerous command, it blocks it instantly. This is the only enforcement that works 100% of the time, even if all other safeguards are turned off.

Add this to your project’s .claude/settings.json (create the file if it does not exist):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$CLAUDE_TOOL_INPUT\" | grep -qiE 'rm -rf|git reset --hard|git push.*--force|git push.*-f|sudo |curl.*\\|.*bash|curl.*\\|.*sh' && exit 2 || exit 0"
          }
        ]
      }
    ]
  }
}

How it works: Before every shell command, Claude Code runs this script. The script checks if the command matches any dangerous pattern (rm -rf, git reset --hard, git push --force, sudo, or piping curl to bash). If it matches, the script exits with code 2, which blocks the command before it runs. If it does not match, the script exits with code 0 and the command proceeds normally.

You can add more patterns by extending the list inside grep -qiE '...'. Separate patterns with | (which means “or”).

Impact on Claude’s usefulness: The hook above blocks rm -rf, git reset --hard, git push --force, sudo, and curl piped to bash or sh. None of these are commands Claude needs for normal work. The hook does not block regular rm (single file), normal git push, or any other everyday command.

Step 4: Enable sandbox mode

Add this to your personal settings file (~/.claude/settings.json), merging with the deny rules from Step 1:

{
  "sandbox": {
    "enabled": true
  }
}

This single setting restricts what Claude Code can access at the operating system level (macOS or Linux only, not available on native Windows). Even if Claude tries to use a workaround to read a blocked file, the operating system itself stops it. According to Anthropic’s own testing, sandboxing reduces permission prompts by 84% because safe operations run freely inside the boundary.

Impact on Claude’s usefulness: Positive. Sandbox mode makes Claude faster, not slower. Because safe operations run freely inside the sandbox boundary, Claude spends less time asking you for permission. This is the one safety step that actively improves the experience.

Step 5: Lock down bypass mode for teams

If multiple developers use Claude Code in your organisation, deploy a managed settings file that prevents anyone from running --dangerously-skip-permissions. Without this lock, a single developer can disable every other safety rule with one command-line flag.

Create the managed settings file at the OS-level path:

Contents:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

This file requires administrator access to create or modify, which means individual developers cannot undo it. It is the single most important enterprise control for Claude Code.

Step 6: Use plan mode before making changes

Before starting any non-trivial task, press Shift+Tab twice (or type /plan) to enter plan mode. In this mode, Claude can read and analyse your code but cannot modify any files or run any commands.

The recommended workflow:

1. Enter plan mode. Ask Claude to read and understand the relevant part of the codebase.
2. Review the plan. Claude proposes what it will do. Read it. Press Ctrl+G to open the plan in your editor.
3. Switch to normal mode. Press Shift+Tab to exit plan mode. Now implement with the plan as context.
4. Review the diff. After changes, run git diff to see exactly what changed before committing.

This turns expensive mistakes into cheap conversations. A plan that reveals a bad approach costs nothing; a bad approach that deletes files costs a lot.

Impact on Claude’s usefulness: Adds one extra step at the start of a task, but saves time overall by catching wrong approaches before any code is written. Most developers who adopt plan mode report fewer mid-session course corrections.

Step 7: Commit early and often

Use git to create save points after every meaningful change. This gives you rollback points if something goes wrong.

git add -A && git commit -m "checkpoint: description of what changed"

Remember what git does not cover:

• Git only tracks files inside the project repository. If Claude modifies your home directory, other projects, or system files, git has no record.
• Uncommitted work is lost if Claude runs git reset --hard or rm -rf.
• Git cannot undo a git push --force that has already overwritten remote history.

The hooks from Step 3 block the most dangerous commands, but frequent commits are your last line of defence for everything else.

Step 8: Move secrets to a password manager

The most durable protection is to never store raw passwords or API keys on the machine at all. Replace raw values in your .env files with references to a secrets vault:

# Before (raw secret, readable by Claude)
DATABASE_PASSWORD=s3cret_p@ssw0rd

# After (vault reference, useless without separate login)
DATABASE_PASSWORD=op://Production/Database/password

Services that support this pattern: 1Password CLI (op:// references), HashiCorp Vault (vault: paths), AWS Secrets Manager, Google Secret Manager, and Azure Key Vault. Even if a leak occurs, the leaked text is just a reference that requires separate authenticated access to resolve.

All eight steps can be completed in under an hour by someone familiar with the tooling. Aurora deploys this baseline on every client engagement before Claude Code reads a single file. If your business is starting to use Claude Code, or evaluating a vendor who uses it on your behalf, this is the minimum viable standard.

Frequently asked questions