Controllable AI Coding: How to Let Claude Code Run Wild Safely

Note: This applies to command-line tools like Claude Code, Codex, and the Gemini CLI.

When we talk about AI coding, we often get stuck on questions like:

• Will the AI make mistakes? Will it randomly delete files?
• Can we force it to be more careful?
• Do I need to manually confirm every single step?

Honestly, these questions are just the tip of the iceberg.

The real problem isn’t whether AI makes mistakes. The real problem is: Are the errors enumerable?

If you can’t list every possible error, then any control method that relies on “human judgment” will eventually fail.

1. The Core Risk of AI Coding

In a real engineering environment, the dangerous part of AI isn’t a specific, known command like:

• rm -rf
• git push
• Overwriting a config file

These risks are easy to block.

The thing that’s truly uncontrollable is this:

AI error paths are combinatorial. You can’t list them all.

Even if you block every “dangerous operation” you can think of today, tomorrow might bring a combination of behaviors you never anticipated.

This means one thing:

As long as safety relies on me being right every time, the system is not controllable in an engineering sense.

2. The Goal: Control Without Predicting Every Risk

We need to redefine the problem.

We shouldn’t be trying to solve:

❌ How to stop AI from making mistakes

We should be solving:

✅ Is it still safe when AI does make mistakes?

In other words:

Don’t try to control the behavior. Control the blast radius.

This is a system design problem, not an AI capability problem.

3. The Ultimate Strategy: Structural Safety

In engineering, there’s only one proven way to handle non-enumerable risks:

Limit the worst-case scenario through structural design.

For AI coding, we can split this structure into two layers:

1. Environment Boundary (Hard Constraint)
2. Execution Boundary (Soft Constraint)

As long as these two layers hold, AI can “explore freely” within the boundaries without causing irreversible damage to the real system.

4. Layer 1: Environment Boundary (Docker Sandbox)

4.1 The Goal

• The AI can only see the project directory.
• The AI cannot touch the host system.
• The AI has no access to sensitive credentials (like SSH keys).

4.2 How It Works

I don’t run Claude Code directly on my host machine. It runs inside a Docker container:

docker run --rm -it \
  -v "$(pwd)":/workspace \
  -w /workspace \
  --cap-drop ALL \
  -e ANTHROPIC_AUTH_TOKEN=... \
  -e ANTHROPIC_BASE_URL=https://open.bigmodel.cn/api/anthropic \
  node:22 \
  npx @anthropic-ai/claude-code

4.3 Why This Matters

• /workspace is the entire world to the AI.
• It can’t see my $HOME, my system configs, or my .ssh folder.
• When the container dies, the state resets to zero.

If I run this inside the container:

ls -la ~/.ssh/

The result is empty (or just known_hosts). No private keys.

The conclusion:

Even if the AI tries to run git push, it physically cannot authenticate. (It can still git add and git commit, so your work is saved, but it can't mess up the remote repo.)

This isn’t a policy. It’s a fact of the environment.

5. Layer 2: Execution Boundary (Permissions)

Docker solves “where it runs,” but we still need to answer:

What is it allowed to do in this world?

Claude Code has a built-in permission model based on commands:

• allow: Run automatically
• ask: Ask for confirmation
• deny: Block immediately

5.1 My Strategy

I keep a settings.json file in the project. The rules are simple:

• High-frequency, reversible, local ops → allow
• Ops that affect external state → ask
• Irreversible or high-risk ops → deny

For example:

• Allow:
• Build, test, refactor
• git diff, git status, git log
• Confirm:
• git pull
• Block:
• git push
• rm -rf
• sudo

5.2 The Key Takeaway

This isn’t about “limiting AI’s capabilities.” It’s about encoding system boundaries into rules so you don’t have to keep them in your head.

6. The Result: No More Babysitting

When you have both layers in place, something interesting happens:

You don’t need to constantly watch the AI anymore.

Why?

• The environment limits the worst-case scenario.
• The permissions limit high-risk actions.
• All failures are local and easy to roll back.

The AI shifts from “something I need to watch” to an autonomous agent I can trust to do the work.

7. Why This Is the Ultimate Way

This approach doesn’t rely on:

• Claude Code getting smarter
• Your prompts being perfect
• You being extra careful

It solves the long-standing problem of how to build a hands-off system when you can’t predict every risk.

This principle applies to everything:

• AI Agents
• Automated Ops
• Overnight tasks
• AI in CI/CD pipelines

8. Conclusion: What Is “Controllable AI Coding”?

Controllable AI Coding isn’t about:

• Reducing the chance of AI making mistakes
• Asking for human confirmation more often

It’s about:

Ensuring that when errors happen, they happen within a precisely limited, rollback-able scope.

With this structure: Claude Code can run wild, because it literally can’t break anything that matters.

This isn’t trusting AI. It’s stopping the habit of building safety on top of “trust”.