Skip to content

Sandboxing AI Agents: From dclaude to ADDT

tools 3 min read

When AI coding agents can navigate your filesystem, one wrong move and they’re “helpfully” editing files in your production branch while you’re working on a feature. I built two tools to solve this — starting with a focused wrapper, then generalizing it into something any agent can use.

dclaude: Containing Claude Code

The first iteration was dclaude — a containerized wrapper for Claude Code that isolates filesystem access using Docker. It’s a drop-in replacement with identical CLI syntax: instead of claude "refactor this", you run dclaude "refactor this" while the AI only sees mounted directories.

  • Passes through all Claude Code CLI flags
  • Auto-builds the container image on first run
  • Single-file install via curl
  • Optional SSH forwarding, GPG signing, Docker-in-Docker
  • Persistent container mode for faster iteration

Started as a bash script, then ported it to Go when the shell complexity got out of hand.

ADDT: AI Don’t Do That

The idea quickly generalized. ADDT (AI Don’t Do That) is a universal tool for safely running any AI coding agent in isolated Docker containers: addt run <agent>.

What it adds beyond basic containerization:

  • Network firewall — restrict which domains an agent can reach
  • Resource limits — configurable CPU and memory constraints for runaway processes
  • Multi-agent support — extensions for Claude, Codex, Gemini, Copilot, Cursor, Amp, Kiro
  • Orchestration platforms — works with Claude Flow, multi-agent setups
  • Transparent aliasing — make it invisible so you just type claude as usual
  • Custom extensions — just a config file and a shell script

Install via Homebrew, point it at your project, and your agents run sandboxed without knowing the difference.

The core insight: the isolation layer should be agent-agnostic. The safety guarantees shouldn’t depend on which AI you’re using.

The sandboxing space is evolving fast. Here are projects tackling similar problems from different angles:

  • claude-docker by Ingmar Krusch — 11 hardening layers including DNS exfiltration blocking and a C library that intercepts git invocations at the binary level. “17 audit rounds and counting.”
  • Claude-Clamp by Richard Gross — built after discovering Claude can disable its own sandbox without user consent. Focuses on network isolation while avoiding Docker-in-Docker.
  • nono.sh by Luke Hinds — kernel-based network blocking with git lockdown.
  • hopx by Bunnyshell — ephemeral MicroVM sandboxes rather than containers.
  • Docker AI Sandboxes — Docker’s official sandboxing for AI agents.
  • Claude Code sandboxing docs — Anthropic’s built-in sandboxing guidance.
  • h-cli by Halil Ibrahim Baysal — another CLI-based approach.

Insights from the Community

“Treat AI agents like untrusted contractors: defense-in-depth, guardrails as infrastructure, not only prompt engineering.” — Ingmar Krusch

“Docker shields the process in the container from the system around, but it has never been a security sandbox. That’s why AWS puts containers on Fargate in tiny virtual machines with Firecracker.” — Jan Ehrhardt

A few patterns emerging:

  • DNS is a blind spot — blocking network access isn’t enough when agents can exfiltrate data through DNS queries. Kill DNS entirely or use allowlists.
  • Git config is an attack surface — git has a surprisingly rich set of config options that agents can exploit. Binary-level interception may be needed.
  • Containers aren’t enough — the consensus is shifting toward MicroVMs (Firecracker) or WebAssembly for stronger isolation boundaries.
  • Agents fight back — Claude can disable its own sandbox, rewrite configs, and find creative escape routes. Security is layers, not a finish line.

Originally posted on LinkedIn and LinkedIn. Related projects sourced from this thread.

Navigate with ← →