"Stop Approving Every Claude Code Command: A .claude/settings.json Guide"

Jeff Sinason — Tue, 14 Apr 2026 23:25:42 +0000

If you've spent any real time with Claude Code, you know the rhythm: prompt → approve → prompt → approve → prompt →
approve. Every shell command, every file edit, every tool call wants a thumbs-up. Secure by default, yes. But fifty
approvals into a feature branch, the friction isn't keeping you safe — it's training you to click "yes" without

reading.

There's a better answer: .claude/settings.json. Pre-approve the command patterns that are safe, keep the destructive
ones gated, and let Claude actually work in the gaps you trust it in.

Here's the exact config I use, what's in it, what's deliberately not in it, and the tradeoffs.

The Configuration

{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(python manage.py *)",
      "Bash(python3 manage.py *)",
      "Bash(pip *)",
      "Bash(pip3 *)",
      "Bash(npm *)",
      "Bash(npx *)",
      "Bash(gh *)",
      "Bash(docker *)",
      "Bash(docker-compose *)",
      "Bash(celery *)",
      "Bash(ls *)",
      "Bash(cd *)",
      "Bash(cat *)",
      "Bash(mkdir *)",
      "Bash(cp *)",
      "Bash(mv *)",
      "Bash(source *)",
      "Bash(python3 *)"
    ]
  }
}

This configuration auto-approves a curated set of shell commands. Let’s break down the reasoning, risks, and recommendations for each category.

What Gets Auto-Approved (and Why)

Version Control & GitHub CLI

Commands: git *, gh *

These are the backbone of any development workflow. Auto-approving them means Claude can check status, create branches, stage files, commit, and interact with GitHub issues and PRs without interruption.

Consideration: git * is broad. It includes git push, git reset --hard, and git branch -D — commands that can alter remote state or destroy local work. If you’re working on a shared repository, a misconfigured push could affect your team. Claude Code is designed to confirm destructive git operations regardless, but the permission layer is your first line of defense.

Recommendation: If you’re working solo on a feature branch, this is low risk. On shared repos with CI/CD pipelines, consider narrowing to specific subcommands like git status, git add, git commit, and git log.

Python & Django

Commands: python3 *, python manage.py *, python3 manage.py *, pip *, pip3 *

For Django projects, this is essential. Claude can run migrations, start the dev server, execute management commands, and install packages without friction.

Consideration: python3 * is the broadest permission in this list. It allows Claude to execute any Python script or one-liner. While Claude Code operates with good intent and guardrails, this theoretically permits arbitrary code execution. The pip * permissions could install packages that modify your environment.

Recommendation: In a virtual environment (which you should always use), pip changes are contained and reversible. The python3 * permission is a pragmatic choice for development speed — but be aware it’s essentially giving Claude full scripting access. If that concerns you, narrow it to python3 manage.py * only.

Node.js Tooling

Commands: npm *, npx *

Standard for any project with JavaScript dependencies, build tools, or frontend assets.

Consideration: npm install can run post-install scripts from third-party packages. npx downloads and executes packages on the fly. Both carry supply-chain risk in general — though in practice, Claude is running the same commands you would.

Recommendation: Acceptable for most development workflows. If you’re security-conscious, audit your package.json scripts and consider using npm ci (clean install) for reproducible builds.

Containers

Commands: docker *, docker-compose *

Useful when your project runs services in containers — databases, Redis, background workers, etc.

Consideration: Docker commands can start/stop containers, build images, and in some configurations access the host filesystem. docker run with volume mounts could theoretically read or write anywhere on your machine.

Recommendation: Safe for standard development workflows (starting services, viewing logs, rebuilding images). Be cautious if your Docker setup involves privileged containers or host network access.

Task Workers

Commands: celery *

For projects using Celery for background task processing.

Consideration: Low risk. Primarily used to start workers, inspect queues, and purge tasks during development.

File Operations

Commands: ls *, cd *, cat *, mkdir *, cp *, mv *, source *

Basic filesystem navigation and manipulation.

Consideration: mv and cp can overwrite files without warning. source executes shell scripts in the current environment, which could modify environment variables or run arbitrary commands.

Recommendation: These are generally safe for development. The source permission is worth noting — it’s typically used for activating virtual environments (source venv/bin/activate), but it could source any script.

What’s Notably Absent

The configuration deliberately excludes several commands:

Command	Why It’s Excluded
`rm`	Can delete files and directories irreversibly
`curl` / `wget`	Can download and execute remote content
`chmod` / `chown`	Can change file permissions and ownership
`sudo`	Elevates privileges — never auto-approve this
`kill` / `pkill`	Can terminate processes
`ssh` / `scp`	Remote access commands

These exclusions are intentional safety boundaries. When Claude needs to use any of these, you’ll get a confirmation prompt — giving you a chance to review exactly what’s being executed.

The Pros

Dramatic workflow speedup. Fewer interruptions means you stay in flow. For iterative tasks like “run tests, fix the failure, run again,” auto-approved commands save dozens of confirmations per session.
Better AI autonomy. Claude Code works best when it can execute multi-step plans without pausing for approval at each step. Auto-approving safe commands lets it behave more like a capable junior developer and less like a tool waiting for permission.
Project-scoped safety. The .claude/settings.json file lives in your project directory, so permissions are scoped to that specific project. Your personal projects can be permissive while client work stays locked down.
Team alignment. Committing the settings file to your repo means every developer on the team gets the same permission baseline. No one has to configure it individually.

The Cons

Broad patterns carry implicit risk. Wildcards like python3 * and git * match more than you might intend. A pattern meant for git status also matches git push --force origin main.
False sense of security. Having a permission file might make you less vigilant about reviewing Claude’s actions. The safety net should complement your attention, not replace it.
Environment-specific assumptions. This configuration assumes a local development environment. The same permissions on a production server or CI runner would be inappropriate.
Supply chain surface area. npm *, pip *, and npx * all interact with package registries. While the risk is the same as running these commands manually, auto-approval means less opportunity to catch unexpected package installations.

Best Practices

Start restrictive, then expand. Begin with only the commands you find yourself approving repeatedly, then add patterns as needed. It’s easier to add permissions than to recover from an unintended action.

Use project-level settings, not global. Keep permissions in .claude/settings.json within each project rather than in your global Claude Code config. Different projects have different risk profiles.

Review the diff, not just the output. Even with auto-approved commands, always review what Claude has changed before committing. The git diff is your ground truth.

Pair with virtual environments. Auto-approved pip and python3 commands are much safer inside a virtual environment, where changes are isolated and reversible.

Never auto-approve destructive commands. Keep rm, sudo, curl, and remote access commands behind the confirmation prompt. The few seconds of friction are worth it.

Conclusion

Claude Code’s permission system is a thoughtful balance between developer velocity and operational safety. The configuration shown here — auto-approving version control, language tooling, containers, and basic file operations while gating destructive commands — represents a practical middle ground for most development workflows.

The key insight is that permissions should match your trust level and environment. A solo developer on a feature branch has different needs than a team working on production infrastructure. Configure accordingly, review regularly, and let Claude Code handle the repetitive work so you can focus on the interesting problems.

At EchoForgeX, we build AI-powered tools and help businesses integrate AI into their workflows. Get in touch to learn how we can help your team work smarter with AI.

I analyzed 8 AI coding tools. Here's what's broken (and what I'm building).

Jeff Sinason — Sun, 04 Jan 2026 20:09:08 +0000

The State of AI Coding Tools in 2026

I spent the last month researching every major AI coding tool:

GitHub Copilot
Cursor
Devin
Replit Agent
Amazon Q Developer
Windsurf
Tabnine
Auto-Claude

Here's what I found.

The Good

Adoption is through the roof. 84% of developers now use AI coding tools in some form. That's up from ~60% just two years ago.

Real productivity gains exist. When AI tools work well, developers report saving 1-2 hours per day on routine coding tasks.

The Bad

Trust is collapsing. Only 29% of developers trust AI accuracy, down from 40% last year. Almost half actively distrust the output.

The productivity paradox. Studies show developers feel 20% faster with AI, but measured performance is actually 19% slower on complex tasks. The time spent reviewing and fixing AI code often exceeds the time saved.

Security concerns. 48% of AI-generated code contains vulnerabilities according to recent research.

The Ugly

The #1 complaint across every survey and forum:

"Almost right, but not quite."

AI generates code that looks correct but has subtle bugs. Developers end up debugging AI code instead of writing their own.

What's Missing

Based on my research, here are the biggest gaps:

Trust & Transparency - No tool shows why it generated specific code
Configurable Autonomy - It's either "suggestions" or "fully autonomous" with nothing in between
Enterprise Control - CISOs want self-hosted options that most tools don't offer
Quality Assurance - No built-in testing or security scanning before code is suggested

I'm Building Something

I think there's an opportunity for a tool that:

Shows confidence levels and explains decisions
Lets you configure exactly how autonomous you want it
Includes built-in testing and security checks
Can be self-hosted for enterprise

But before I build anything, I want to validate these assumptions.

Help Me Out?

I created a quick survey (3 minutes) to understand what developers actually need:

[https://docs.google.com/forms/d/e/1FAIpQLSfwTmpGab8_ViLFUqjPXHhiKdclzsCGxf7RucedyWzGUkeSQQ/viewform?utm_source=devto&utm_medium=article&utm_campaign=devai-survey] AI Development Survey

DEV Community: Jeff Sinason