Where should your code live in a Docker Sandbox?
Docker Sandboxes represent a significant shift in how developers run untrusted or experimental code safely. Rather than spinning up full containers or worrying about code execution environments, Sandboxes provide isolated execution spaces that you can control precisely. But before you start running code in a Sandbox, you need to decide where that code lives and how it gets there. Docker gives you three primary options: shared mounts, Git worktrees, and clone mode. Each approach has different tradeoffs around security, performance, and workflow flexibility, and choosing the right one depends on your specific use case.
Shared mounts are the most straightforward approach. You mount a directory from your host machine directly into the Sandbox, similar to how you’d use Docker volumes. This means your code lives on your host filesystem, and the Sandbox accesses it in real-time. The technical advantage here is speed—there’s no copying or cloning overhead, and changes you make locally are immediately visible inside the Sandbox. This works particularly well when you’re actively developing and iterating, or when you’re running AI agents that need to read and write files constantly. However, shared mounts expose more of your host filesystem to the Sandbox environment, which could be a security consideration if you’re running untrusted code. Think of this option as best for trusted or in-house development workflows where convenience and live iteration matter most.
Git worktrees offer a middle ground between security and convenience. Instead of mounting your filesystem directly, you point the Sandbox to a Git repository and branch. Docker pulls the code into the Sandbox using Git, giving you a clean, versioned copy without exposing your entire host system. This approach is excellent when you want reproducibility—the Sandbox always runs a specific commit or branch, making it easy to debug exactly which version of code caused a problem. It’s also ideal for CI/CD pipelines or when you’re integrating external code from teammates. The tradeoff is that changes inside the Sandbox aren’t automatically reflected on your host, and you need a Git repository set up. This is your go-to choice when you need audit trails and version control built into your execution environment.
Clone mode takes isolation furthest by creating a complete, independent copy of your code within the Sandbox at startup. This is the most secure option—the Sandbox gets its own copy that’s fully isolated from your host system, so any code changes or side effects stay contained. It’s slightly slower than shared mounts because of the initial copy overhead, but that penalty is often worth the isolation guarantee. Clone mode shines when you’re running AI agents on untrusted code, executing third-party scripts in production, or when you need guarantees that the Sandbox won’t interfere with anything on your host. If you’re building a platform where users submit code to run, clone mode should be your default choice. The practical trade-off is that you lose live iteration—if the code needs to change, you’ll need to restart the Sandbox—but that constraint often improves reproducibility and prevents accidental state mutations.
The right choice depends on where you sit on the spectrum between speed-of-development and security-of-isolation. Use shared mounts when you’re experimenting locally and trust your environment. Reach for Git worktrees when you need version control and reproducibility in team settings. Pick clone mode when security and complete isolation are your priority, especially in production systems running untrusted workloads. As your automation sophistication grows, you may find yourself using all three depending on context—and Docker Sandboxes give you the flexibility to switch between them based on what each workflow actually requires.