@vincemask: https://x.com/vincemask/status/2064581609928699973
Summary
This article introduces the five-layer safety guardrail configuration of Claude Code, including OS sandbox, native permission rules, PreToolUse Hook, engineering rules, and remote access control. It also provides a deny/ask/allow configuration and command classification list to ensure the Agent operates autonomously within secure boundaries.
View Cached Full Text
Cached at: 06/10/26, 03:56 PM
Don’t Let Claude Code Delete Your Code Accidentally: These 5 Security Layers Are a Must
Once Claude Code gets file modification, command execution, and Git operation permissions, efficiency skyrockets—but so does risk. A single wrong rm, an accidental database reset, or a force push that bypasses checks can cause irreversible damage.
Relying solely on prompt instructions like “don’t execute dangerous operations” is far from enough. A truly reliable solution requires a layered safety mechanism spanning the execution environment, native permissions, dynamic hooks, engineering rules, and the remote repository.
This article breaks down the 5 security layers for Claude Code and provides ready-to-use deny, ask, allow configurations and a categorized command risk list—so your agent can operate autonomously as much as possible within safe boundaries.
Three hard lines of defense (sandbox → permission rules → PreToolUse Hook), plus two soft barriers (engineering rules → remote gating). Listed from strongest to weakest.
Layer 1: OS Sandbox & Credential Isolation
The deepest layer. Restricts filesystem, network, secrets, and execution environment. Claude Code natively supports sandbox.filesystem, which applies to all child processes (kubectl, terraform, npm, etc.)—not just Claude’s own tool calls.
Only when this layer is in place do the subsequent layers become meaningful.
Layer 2: Native Permission Rules — deny / ask / allow
The most reliable command control layer. Claude Code’s native permission system matches in the order deny → ask → allow.
Directly blocked (deny)
Requires confirmation (ask)
Directly allowed (allow)
Native permissions are a true hard boundary, taking priority over hooks. Hooks are suitable for dynamic context-dependent policies, not as a sole line of defense.
Layer 3: PreToolUse Hook — Dynamic Policies
Native permissions handle “fixed rules”; hooks handle decisions that depend on context—such as the current branch, target ref, or command argument combination.
Script (shared core)
Key fix: The matcher must cover Bash|Read|Edit|Write. Matching only Bash won’t block file tools.
Fixed-string matching can be bypassed (rm -r -f /, git push -f, bash -c '...', etc.). Hooks are policy aids, not security sandboxes. Put strong constraints in native deny.
Claude Code configuration — .claude/settings.json
Claude Code’s PreToolUse supports returning
permissionDecision: "allow" | "deny" | "ask"via JSON. Exit code 2 is equivalent todeny.askshows a confirmation dialog.
Codex configuration — .codex/hooks.json
Codex’s PreToolUse supports returning via JSON:
Also supports the legacy format {"decision": "block", "reason": "..."}. Exit code 2 also works. However, permissionDecision: "ask" is currently not supported—if returned, the hook is marked as failed and execution continues.
Hooks configuration reference article
Vince聊开发@vincemask·May 13 ArticleFrom 0: Building an Automated Claude Code Workflow with HooksYou ask Claude Code to write features, add tests, format files, and finally commit. It writes the features, fills most of the tests, formats two files, but misses one. Then it casually tells you: “All done.” You check: no commit, formatting not fully aligned…1882370134K
Layer 4: Engineering Rules — CLAUDE.md / .claude/rules/
Permissions prevent disasters; rules prevent technical debt.
Under .claude/rules/, one rule per line:
Examples:
-
Prohibit inline validation schemas; place all in
types/directory -
Prohibit cross-domain dependencies
-
Auth logic is read-only; do not redesign
-
Search shared packages before writing new functions
-
Protect
.husky/and related config files; do not modify
Reference article:
Vince聊开发@vincemask·May 19 ArticleClaude Code Engineering Guide: Efficiently Organize Your .claude/ DirectoryWhy Structure Matters? Most Claude Code users know the .claude/ folder exists, but few seriously consider its organization. On small projects, a single…86122530K
Layer 5: Remote Gatekeeping — CI + Branch Protection
Local hooks and agent guards are only the first line of defense. The following are the final control points.
Husky (local quality gate, can be bypassed)
Husky can be bypassed via: git commit --no-verify, git push --no-verify, HUSKY=0 git commit, git -c core.hooksPath=/dev/null commit.
So you must pair it with:
-
Native permission blocking of
--no-verifyparameters -
Remote CI re-running lint + test
-
Branch protection requiring CI to pass
Remote Repository Policies (non-bypassable)
GitHub/GitLab branch protection:
- Prohibit force push
- Require PR review
- Require CI status checks to pass
- Prohibit direct push to main
The rule “feature branches can push, main cannot” relies on remote branch protection rules, not local agent configuration.
Command Risk Level Quick Reference
git add modifies the index, git checkout -b creates a branch, gh pr create creates a remote PR—none are read-only and should not be blindly whitelisted.
Dual Tool Adaptation: Claude Code + Codex
The core Bash command detection script can be reused. Both tools’ PreToolUse Command Hook receive JSON from stdin, and exit code 2 can block the call.
Implementation Suggestions
Keep your deny and allow lists consistent, but maintain thin adaptation layers separately. Do not assume that all hook events and decision fields from both sides will remain fully compatible in the long term.
How to Get Started
-
First, configure native
permissions.denycovering the most dangerous operations -
Then add
permissions.askcovering remote-side-effect operations that need confirmation -
Then add
permissions.allowfor read-only and locally reversible operations -
Use PreToolUse Hook for dynamic checks (branch detection, argument combinations, etc.)
-
Place engineering rules in
CLAUDE.md/rules -
Use remote CI and branch protection as the ultimate safety net
If this article helped you:
- Bookmark it.
- For more Claude Code practices, follow @vincemask
If this article helped you:
-
Bookmark it.
-
For more Claude Code practices, follow @vincemask
Recommended Reading
-
Claude Code Advanced Usage: 10 Plugins to Build a Complete Development Workflow
-
How to Cut Claude Code Token Consumption by 90%+ with 5 Tools + Custom Hooks
-
Antigravity CLI Getting Started Guide: From Installation to First Run
-
claude-code-setup Plugin Practical Guide: Let Claude Code Truly Understand Your Project
-
Claude Code Engineering Guide: Efficiently Organize Your .claude/ Directory
-
Claude Code Slash Command Complete Guide: 14 Practical Tips
-
From 0: Building an Automated Claude Code Workflow with Hooks
-
8 Tips for Writing CLAUDE.md: Let Claude Code Understand Your Project Better
-
MEMORY.md Usage Guide for Claude Code Projects
Similar Articles
@thinkszyg: https://x.com/thinkszyg/status/2066837941477920993
A practical guide for developers (especially AI coding tool users) on how to safely and efficiently use Claude Code, Codex, and other tools for multi-agent parallel development, focusing on best practices such as task decomposition, file isolation (worktree), boundary control, sequential merging, etc., to avoid file conflicts and chaos.
@alswl: Is there any community solution to run Claude Code and Codex in a container (or virtualized environment) as a local tool, like Vagrant back in the day? I'm increasingly concerned about the high permissions and unpredictability of agent software.
The user asks if there is a local tool similar to Vagrant that can run Claude Code and Codex in containers or virtualized environments, to alleviate concerns about excessive permissions and unpredictability of agent software.
@yibie: Recommended — Anthropic's engineering team writes up their two years of security isolation experience for all Claude products. Not a security whitepaper — it's an engineering document with incident postmortems and fixes. Three isolation modes (ephemeral containers / HITL sandbox / local VM), six pitfalls they encountered, …
Anthropic's engineering team shares their complete experience from over two years of security isolation for Claude products, including three isolation modes (ephemeral containers / HITL sandbox / local VM) and six incident postmortems with fixes, emphasizing environment-layer defense over model-layer.
@vincemask: Many people use Claude Code but only have one CLAUDE.md in their project. A truly maintainable configuration is typically broken down into layers: 1. CLAUDE.md: Project-level context and conventions 2. settings.json: Permissions, model, and hooks 3. rules/: Split rules by topic 4. commands/: Settle repeatable workflows 5. skills/: Dynamically load based on task context 6. agents/: Define dedicated sub-agents 7. hooks/: Auto-validate before and after tool calls. When you have a lot of configurations, don't cram them all into one file. The clearer the layering, the more stable Claude Code becomes, and the easier it is to maintain and reuse. Here is a project structure diagram for your reference.
Recommended layered approach for Claude Code project configuration, splitting config into CLAUDE.md, settings.json, rules/, commands/, skills/, agents/, hooks/, etc., to improve maintainability and reusability.
@vintcessun: An 8-stage vulnerability discovery agent that runs on a Claude subscription, essentially a reproduction of the Cloudflare Project Glasswing paper. Multiple narrow agents + intentional disagreement verification + reachability gating, breaking down 'which piece of code can actually be exploited by an attacker' into 8 precise steps. Recon uses Opus to decompose tasks, H…
Introduces an 8-stage vulnerability discovery agent based on Claude subscription, reproducing the core ideas of the Cloudflare Project Glasswing paper. It uses multiple narrow agents, intentional disagreement verification, and reachability gating to break down exploit analysis into precise steps, without the need for API keys.