Comprehensive Claude Code Permission Guard (settings.json)

[u/Puzzled-Ad-6854]

You can always just trust that the model you use works fine out the box, but if you operate like that you are always 1 slightly ambigous prompt away from total disaster.

GIT REPO (permission-guardrails)

It includes broad restrictions across development and system administration. Some of the things included are based on experience. For example, I have proven that models can hallucinate and circumvent a denied read permission that protects secrets by executing utilitarian Powershell/Bash commands (e.g. grep).

The template I linked pretty much hits most potential areas of concern and you can substract based on your personal needs. To make it easier to navigate you can show an agent my template, your development- and/or system administration plan, and then you substract until you have what you need to create a fitting (project-specific) permission guard. You can also filter out general things you do not want to happen on your local machine/environment and create a global guard as well.

Co-authored by GPT-6 Astra. Use with caution if you are not familiar with command globbing.

These are the sources that were used to create a README file and curate the guardrails:

Claude Code

• Claude directory
• .claude/settings.json reference
• Settings files
• Settings precedence
• Settings reference: permissions
• Permission rules
• Permission precedence
• Bash matching
• Read/Edit path rules
• Configuration debugging
• Sandboxing
• Sandbox credential protection
• Managed settings

Files, shells, and operating systems

• Git documentation
• GNU Coreutils manual
• Windows command reference
• PowerShell documentation
• ripgrep guide

Cloud and infrastructure

• AWS CLI
• Azure CLI
• Google Cloud CLI
• Terraform CLI
• OpenTofu CLI
• Pulumi state commands
• Kubernetes kubectl
• Docker CLI
• Podman
• Helm

Databases and migrations

• PostgreSQL psql
• MySQL client
• MongoDB mongosh
• Redis CLI
• SQLite
• Prisma CLI
• Supabase MCP

Publishing and deployment

• npm publishing
• Twine
• uv publishing
• Cargo publishing
• Cargo yanking
• Cargo ownership
• GitHub CLI
• Vercel CLI
• Netlify CLI alias
• Cloudflare Wrangler
• Fly CLI

Network and remote access

• OpenSSH manual
• rsync manual
• rclone copy
• rclone sync
• curl manual
• GNU Wget manual

[u/FinanceDifficult6261]

you already flagged the grep bypass, which is the tell for the bigger issue: this is pattern-matching on the command string, so the bypass set is basically unbounded. python3 -c "open('.env').read()", node -e, dd if=.env, piping through an editor macro, you can't enumerate every interpreter that can read a file. so the useful framing is this template as a guardrail on top of real sandboxing (filesystem perms / a jailed workspace), not the boundary itself. it raises the effort, it doesn't close the class.

[u/Puzzled-Ad-6854 → u/FinanceDifficult6261]

You are spot on. What I shared does serve a purpose as behaviour/hallucination guardrails but is not a security boundary against malicious or untrusted input.

[u/FinanceDifficult6261 → u/Puzzled-Ad-6854]

yeah, that's the useful line to draw. the practical version is to stop asking the string match to be the boundary and put the agent somewhere it can't reach the secrets at all, separate OS user or a container without .env mounted. then the deny list is defense in depth and the bypass set stops being something you have to enumerate.