Inside `okdt/claude-code-hardening-cheatsheet`: The Policy Layer That Puts Claude Code on a Leash

A practical hardening template for Claude Code that turns agentic coding from “hope it behaves” into explicit least-privilege controls, sandboxing, and human checkpoints.

8 min read • View on GitHub • More from okdt

A terminal window sits behind a three-lane security gate, with one lane blocked, one lane paused at a review desk, and one lane open. The scene explains that Claude Code needs runtime policy, not just careful prompting, because commands and files are both part of the attack surface. — Claude Code is useful enough to deserve trust boundaries. This repo shows how to draw them before the agent touches the keyboard.

Key Takeaways

Claude Code is treated here like an untrusted local operator, so the real product is enforcement, not advice.
The repo’s center of gravity is a three-tier policy model: deny, ask, and allow.
Sandboxing matters because command control alone does not stop credential leakage from nearby directories.
This is less a Claude Code tweak than a reusable pattern for how AI tools will ship with their own security dotfiles.

Claude Code is powerful enough to feel like local remote code execution. It can run shell commands, touch files, talk to external services, and keep going without waiting for your caution to catch up. That is why a hardening guide like okdt/claude-code-hardening-cheatsheet matters. It treats the agent as a system that needs boundaries, not encouragement.

The repo’s thesis is blunt: if something should not happen, stop it in configuration. That is a different mindset from prompt hygiene or “be careful” habits. The project turns Claude Code into a policy-governed tool, with explicit rules for what gets blocked, what needs approval, and what can proceed automatically.

The repo’s thesis is simple: stop asking, start enforcing

A minimal, opinionated security hardening template for Claude Code settings.json

okdt/claude-code-hardening-cheatsheet, GitHub Repository README · okdt/claude-code-hardening-cheatsheet - GitHub

That line from the README captures the whole posture. The guide is not trying to make Claude Code “safer” in the abstract. It is trying to make risky actions impossible by default, reviewable when necessary, and ordinary only when they are genuinely low risk.

`settings_example.jsonc` is the whole game

The core artifact is settings_example.jsonc, a commented policy file you adapt into your own Claude Code setup. The model is easy to remember and easy to explain: deny for destructive commands, ask for human checkpoints, and allow for routine commands that do not deserve a pause.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push -f *)"
    ],
    "ask": [
      "Bash(git push)",
      "Bash(npm install)"
    ],
    "allow": [
      "Bash(git status)",
      "Bash(npm test)"
    ]
  }
}

A close-up conveyor shows three command cards moving through a policy engine. A destructive command hits a hard stop, a publish command pauses at a human stamp desk, and a harmless status command passes through a green lane. Beneath the conveyor, a separate barrier keeps credential vaults outside the agent’s reach, showing that command policy and filesystem policy are different layers. — The useful mental model is not “AI safety.” It is a routing table for commands, plus a separate wall around sensitive files.

This is where the repo gets practical. The deny list catches destructive shell patterns like force pushes or recursive deletes. The ask list is for actions that are common, but worth a pause. The allow list keeps the agent moving for low-risk checks, so the hardening does not become friction for everything.

The useful distinction is that command governance and filesystem governance are separate controls. One blocks bad actions. The other blocks bad reach.

That separation matters. A command can be safe in isolation and still become dangerous when it has access to the wrong files. The repo pushes you to think in layers: classify the command, then constrain what the process can see, then add hooks for cases that need custom logic.

Sandboxing adds the part most people miss

The cheatsheet does not stop at command filtering. It also emphasizes sandboxing and explicit read denial for sensitive paths like ~/.ssh, ~/.aws, ~/.gnupg, and cloud config directories. That is the real defense-in-depth move. A prompt injection that slips past command rules still should not be able to rummage through your secrets.

Approach	Enforcement style	What it protects	Weakness if used alone
Prompt-only caution	Advice and reminders	Nothing by force	Depends on perfect judgment under pressure
Official Claude Code docs	Baseline configuration guidance	Core usage and syntax	Useful, but not opinionated enough for hard boundaries
okdt hardening template	Runtime policy and sandbox rules	Commands, files, and checkpoints	Requires setup discipline and periodic review

The repo also connects the practice to OWASP thinking, especially excessive agency and prompt injection. That framing is useful because it moves the conversation away from vibes. The risk is not that the model “means well.” The risk is that it acts with too much power for the context it is in.

Riotaro OKADA says the quiet part out loud in the project’s public write-up: Claude Code can be excellent and still trigger damage through overconfident automation. The point is not to distrust the tool emotionally. It is to remove its ability to make irreversible mistakes casually.

Why this is more than a Claude Code tuning guide

The repo is Claude Code specific, but the pattern is broader than one CLI. It is a template for any agentic tool that can touch a terminal, a filesystem, and a network. That is why the project feels like an early version of a new dotfile category. Developers already share shell configs, editor configs, and devcontainer files. Security policies for AI tools are headed there too.

Artifact	What it does	Why it matters
Shell dotfiles	Shape the local command experience	They are already treated as part of developer identity
Editor configs	Tune productivity and defaults	They make workflows portable across machines
Claude Code hardening configs	Constrain agent behavior at runtime	They turn AI assistance into a governed system

That is the larger shift. The useful question is no longer only “what should the model know?” It is “what should the model be allowed to do?” This repo answers with a working configuration file, not a lecture.