Claude Code Approval and Sandbox Guide | Safe Daily Settings for Real Work

Claude Code gets dangerous only when the workflow around it stays vague. Many teams say they are “safe” because approvals are enabled. In practice, that often means people keep clicking “yes” until approvals become background noise.

This article is for the next step after getting started: you already know Claude Code is useful, but you want a daily setup that lets it read code, run tests, draft changes, and help with content or deploy work without turning every session into a trust exercise.

If you want the broader mental model first, pair this with the harness engineering guide, the full permissions guide, and security failure cases. This article focuses on the practical question most teams hit next:

Which actions should be automatic, which should ask, and which should be blocked outright?

Approval is not the same thing as safety

An approval dialog is only one layer. A safer Claude Code setup combines three controls:

Control	What it does	Typical use
Permission rules	Define allow / ask / deny boundaries	Secrets, destructive commands, deploy actions
Approval flow	Put humans in front of irreversible side effects	git push, deploy, send email, DB writes
Sandbox	Reduce what shell commands can touch even if they run	Safer builds, script execution, exploratory tasks

Anthropic’s official docs are worth keeping open while you set this up: Claude Code permissions, settings, and hooks. The permissions documentation explains that read-only tools can run without approval, while shell commands and file modifications can require review. The settings documentation covers scoped settings and permission precedence. The hooks documentation shows how to run deterministic checks before or after tool use.

That distinction matters. If your repo is configured as “ask for everything,” you will create approval fatigue. If it is configured as “allow almost everything,” you will eventually approve the wrong side effect. Good setup is not maximum friction or maximum freedom. It is high trust for reversible work, high friction for irreversible work.

The simplest split for daily work

For most solo developers and small teams, this split is enough:

Action	Default	Why
Read files, grep logs, inspect diffs	Allow	Low risk, high value
Build, test, lint, analytics scripts	Allow	Needed for fast iteration
Edit source files on a branch	Ask or session-allow	Depends on repo maturity
git push, deploy, publish, send email	Ask	External side effect
Read .env, rotate secrets, rm -rf, git reset --hard	Deny	High blast radius
Third-party write APIs	Ask	Real-world consequences

The important nuance is the middle row. File edits are not automatically “safe.” In a personal sandbox repo, session-level allowance can be reasonable. In a production repo with weak tests, keep edits in ask until you trust the surrounding checks.

This is also where dangerous prompt patterns come in. If your prompt says “skip permissions” or “just do the fastest thing,” you are removing the very layer that would have caught the mistake.

A copy-paste baseline for .claude/settings.json

Start with a project-level file that separates reversible work from real side effects.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

Three things are happening here:

1. Read-heavy work stays fast.
2. Anything that escapes the local machine asks first.
3. A small set of obviously dangerous patterns is blocked completely.

If your environment does not support sandboxing, keep the same allow / ask / deny split and move more side-effecting work into ask. At the time of writing, the current official sandbox settings page describes bash sandboxing for macOS, Linux, and WSL2. If you work on Windows without an equivalent boundary, treat deploy, publish, and secret-adjacent commands more conservatively.

Hooks make bad habits harder

Permissions control whether a tool may run. Hooks control what happens around it. That combination is where the setup becomes trustworthy.

Here is a practical hook pattern for content or app repos:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

For Windows repos, replace the grep command with findstr or a small Node.js script. The pattern matters more than the exact shell syntax:

• block obviously bad staged files before commit
• force a build before deploy
• run deterministic checks after edits

If you already use Claude Code hooks, the next improvement is not “add more hooks everywhere.” It is “put hooks only where they change behavior.” One blocking hook and one verification hook are often enough to change team habits.

Three real workflows

1. A content site

For a multilingual content site, safe automation is not “write a post.” It is:

1. read the last 7 days of analytics
2. pick a topic adjacent to proven traffic
3. create the new article
4. create the locale variants
5. build
6. deploy
7. open the public URL
8. verify mobile layout with Playwright

In this workflow, writing can be fast. Deploy, push, and public verification should still ask or be hook-protected. On ClaudeCodeLab itself, today’s safer rule became: publish one new article, then improve one existing asset, then verify every locale URL on mobile before calling the run done.

2. An app repository

In a product repo, Claude Code can safely handle:

• code search
• diff analysis
• refactoring inside a branch
• build and test loops

It should still ask before:

• pushing to shared branches
• applying DB migrations
• calling production admin APIs
• changing infra or deploy state

This is where security best practices and production incidents become directly practical rather than theoretical.

3. Outreach or back-office automation

Agents are great at research and drafting. They are much more dangerous at sending.

Let the agent:

• read public websites
• classify leads
• draft a landing page
• write an email draft

Do not let it send email, change a live CRM record, or publish assets without approval. The clean split is:

• drafting: allow
• publishing or sending: ask
• destructive cleanup or secret reads: deny

The failure cases to avoid

Failure 1: “Ask everything”

This feels safe for one day and unsafe by week two. Eventually you stop reading prompts and start approving rhythmically. That is worse than a clear deny list because it creates the illusion of care.

Failure 2: --dangerously-skip-permissions becomes normal

The official permissions docs and every real incident log point the same way: skipping the guard rail is only reasonable in tightly controlled automation. If it becomes your daily default, you are no longer doing supervised agent work. You are gambling with side effects.

Failure 3: build success is treated as release success

This is the most common content-ops mistake. The build passes, so everybody assumes the work is live. Then the public URL is stale, one locale is missing, or the CTA is broken on mobile. Approval and sandbox settings do not fix that. Verification does.

A rollout checklist that actually works

Use this order:

1. Put secrets and destructive commands in deny.
2. Put deploy, publish, send, and push actions in ask.
3. Keep read-heavy inspection and test commands in allow.
4. Add one blocking hook and one verification hook.
5. Require public URL checks for any deploy workflow.
6. Review your approvals once a week and move repetitive safe actions into allow only when the surrounding tests are good enough.

That last step is where most teams improve. The goal is not to stay nervous forever. The goal is to earn automation gradually.

What we changed in practice

We used this exact thinking on ClaudeCodeLab today. Instead of treating the daily automation as “ship something,” the new rule is stricter:

• one new article must be published every run
• one existing task must also move forward
• Playwright must verify the new article on mobile
• every language URL for that article must be checked in production

That small change is more valuable than adding another vague warning to a prompt. Safer agents come from clearer operating rules, not from hope.

Next step

If you want a quick daily reference, start with the free cheatsheet. If you want copy-paste settings, hooks, CLAUDE.md patterns, and team-safe setup examples, get The Complete Claude Code Setup & Configuration Guide. If your team wants help designing rollout rules, review flow, or safe automation boundaries, use the consultation page.