Claude Code Security Model, Permissions, and Safe Workflow Practices

Why Claude Code Requires Security Thinking

Claude Code is a genuinely powerful tool. It reads files, writes files, runs shell commands, and executes code — on your real local filesystem. This is what makes it useful. It is also why understanding its security model matters before you use it on anything important.

What Leaves Your Machine

When Claude Code reads a file, the file contents are sent to Anthropic's API as part of the prompt context. When it runs a shell command, the output is also sent. This is how Claude Code understands your project.

For most developers: The same considerations that apply to any AI API apply here. If you would paste a file into Claude.ai, you would be comfortable with Claude Code reading it.

For enterprise or regulated environments: Review Anthropic's data processing agreements before using Claude Code on code subject to data residency or confidentiality requirements. Claude Code reads files on demand rather than uploading everything proactively — but reads do reach the API.

Practical steps: Use .env for credentials, ensure .gitignore covers sensitive files, and understand that Claude Code reads what it can access in the working directory.

The Permission System

Every time Claude Code wants to take an action, it presents a prompt:

Claude wants to run: npm test
[y]es / [n]o / [a]lways / [s]kip

y — Allow this once. You will see the prompt again next time.

n — Deny. Claude Code tries an alternative.

a — Always allow this command pattern for the rest of the session.

s — Skip this step entirely. Claude Code proceeds without it.

Engaging with these prompts actively maintains your visibility. Reflexively hitting "y" without reading removes the safety value of the system.

Configuring Persistent Auto-Approvals

For commands you consistently trust, configure auto-approvals:

{
  "allowedTools": [
    "Bash(npm test*)",
    "Bash(npm run test*)",
    "Bash(npm run typecheck*)",
    "Bash(npx vitest*)",
    "Bash(git status*)",
    "Bash(git diff*)",
    "Bash(git log*)"
  ]
}

Pattern syntax: Bash(npm test*) matches any command starting with npm test.

Safe to Auto-Approve

• Test runners: npm test, npx vitest, pytest
• Type checking: tsc --noEmit, npm run typecheck
• Read-only git: git status, git diff, git log, git show
• Linting in check mode (not auto-fix mode)

Require Manual Approval Every Time

• `git commit` — Read the diff before committing. Always.
• `git push` — Irreversible. Never auto-approve.
• `npm install [package]` — New dependencies affect the whole team.
• Database migrations — Schema changes can cause data loss.
• Deploy commands — Production impact requires a human decision.
• Any command with `--force` or `-f` — These flags bypass safety checks.

The --dangerously-skip-permissions Flag

This flag disables all permission prompts and auto-approves every tool use.

Appropriate contexts:

# CI/CD pipeline with a fully controlled environment
claude --dangerously-skip-permissions -p "Run tests and fix failures"

# Docker sandbox — changes discarded on container exit

Inappropriate:

• Interactive development sessions on real codebases
• Environments with live credentials
• Any context where you have not thought through what auto-approving everything means

If you use this flag, git must be underneath it.

Git: The Non-Negotiable Safety Layer

Before every session:

git status          # Must be clean. If not:
git stash           # Stash in-progress work

After every session:

git diff            # Read every change
git add -p          # Stage interactively, hunk by hunk
                    # [y]es / [n]o / [q]uit per hunk
git commit          # Only after reviewing everything

Interactive staging (`git add -p`) is the habit that catches subtle problems. Claude Code may touch configuration files while implementing a feature. File-by-file, hunk-by-hunk review surfaces this before it enters your commit history.

If something went wrong:

git checkout .      # Discard all unstaged changes
git clean -fd       # Remove untracked files from session

CLAUDE.md Security Considerations

CLAUDE.md is a trusted instructions file — Claude Code follows it. If your project accepts external contributions, a malicious CLAUDE.md in a pull request could instruct Claude Code to take harmful actions when you review the PR locally.

Review CLAUDE.md changes in PRs with the same scrutiny you would give to GitHub Actions workflows, CI configuration files, or any other file that controls automated behavior in your environment.

Three Things to Do Before Your First Session

1. Verify git is initialized with a clean working tree. Not optional.

1. Write or generate a CLAUDE.md. Prevents Claude Code from making architectural decisions that contradict your project's patterns. Use /init to generate a draft, then review and augment it.

1. Configure allowed tools. Auto-approve your test runner and type checker. Leave everything else requiring manual approval.

These take 15 minutes and prevent the most common Claude Code problems.

The Mental Model

Claude Code has full access to your working directory. You review its work before accepting it. You control what reaches production.

Same model as a capable contractor: access to the files they need, work reviewed before acceptance, no unilateral authority over deployments.

The tool is powerful. The controls are yours.

For the installation walkthrough, CLAUDE.md depth, and workflow patterns: The Complete Guide to Claude Code.