Claude Code is remarkable. It runs shell commands, reads and writes files, connects to external services, and works autonomously toward your goals. Honestly, I can't go back to working without it.
But then I caught myself. I was reflexively moving to "yes" and slamming ENTER on every permission prompt. When you're in the zone, you don't want to stop and read what it's asking. But what if that "yes" was for rm -rf? Or git push --force? Or worse — some abstract task that internally triggers a cascade of deletions or publications, and "undo" isn't an option?
The Risks Are Real
Claude Code doesn't have malicious intent. But it can hallucinate. It can take well-intentioned actions that go far beyond what you asked for — deleting files to "clean up," force-pushing to "fix" a branch, installing packages you never requested. Good intentions, excessive action.
Then there's indirect prompt injection. The source code, documents, and web pages that Claude Code processes during normal work could contain hidden instructions. An attacker embeds a malicious prompt in a dependency or a document, and Claude follows it without question.
And here's one that keeps me up at night: we've always had risk scenarios for local exploits — what happens when an attacker gains user-level access to your machine. Now imagine Claude Code is sitting there too, with the ability to run any command your user account can run. The blast radius just got a lot bigger.
These map directly to the OWASP Top 10 for LLM Applications: Overreliance (LLM09), Excessive Agency (LLM06), and Prompt Injection (LLM01).
Sandbox First
Everyone should enable sandboxing. It's the strongest protection layer available — OS-level isolation of file and network access. Just run /sandbox in Claude Code's interactive mode. The cheatsheet covers the setup and configuration.
Here's why it matters: deny rules alone have gaps. If you deny Read(**/.env), Claude's built-in Read tool is blocked. But cat .env through Bash? That goes right through. Read deny and Bash deny are separate layers that don't cover each other. The sandbox catches what deny rules miss.
What Claude Code's settings.json Can Do
Claude Code has a ~/.claude/settings.json file that controls permissions:
- deny — commands that are always blocked, no prompt
- ask — commands that always prompt, even if you previously said "don't ask again"
- allow — commands that are always permitted without prompting
Put rm -rf, sudo, and git push --force in your deny list, and Claude Code simply can't execute them, no matter how much it "wants" to.
But database commands like psql? If you deny those, you block SELECT and DROP TABLE alike. For these, ask is the practical choice — you get prompted every time and can check what's actually being run.
The "Your Brain" Problem
My favorite line in the whole cheatsheet is in the permission levels table:
| Permission | Behavior | Where to set |
|---|---|---|
| (default) | Prompted on first use; "don't ask again" makes it permanent | Your brain — which may say yes too quickly when busy, or can't tell safe from unsafe when tired |
The default behavior is "ask the user." But the judgment happens in your brain. The one that's rushing to meet a deadline. The one that's not sure what chmod -R actually does in this context. The one that already said "don't ask again" three prompts ago.
That's why deny exists. It doesn't get tired. It doesn't rush. It doesn't second-guess itself.
The Cheatsheet
I organized all of this into a cheatsheet and published it on GitHub. I plan to keep updating it, so issues and pull requests are welcome.
okdt/claude-code-hardening-cheatsheet
Read the README and full cheatsheet here.
It covers:
- Why Claude Code needs hardening (risk scenarios with references to OWASP LLM Top 10)
- Sandbox setup — everyone should do this
- The permission system: deny, ask, allow, and how they interact
- Deny lists by threat category (git ops, file deletion, privilege escalation, remote access, macOS-specific commands, and more)
- Human-in-the-Loop (HITL) with
askrules - Limitations of deny rules and defense in depth with Hooks
Available in both English and Japanese. Loosely styled after the OWASP Cheat Sheet Series — whether it ends up there is another question, but the structure is ready.
How to Use It
Clone the repo and review settings_example.jsonc. Don't copy it blindly — read the cheatsheet to understand why each rule exists, then pick what applies to your environment.
The deny list is a sample of what I wanted to block first. It's not exhaustive. Your environment is different from mine.
Licensed under CC BY-SA 4.0. Use it freely for documentation, training materials, or anything else — just let me know if you do, I'd love to hear about it. If you modify it, share under the same license. Feedback and additional rules for other platforms are welcome.
Now, if you'll excuse me, I'm going to go make some coffee.
Repository: okdt/claude-code-hardening-cheatsheet
Top comments (0)