How to run Claude Code autonomously: Docker isolation and orchestration

Running Claude Code autonomously means using --dangerously-skip-permissions so the agent doesn't stop to ask you before every file write or shell command. On bare metal, this is risky — the agent has access to your whole machine. Inside a Docker container, the risk is contained: the agent can only touch what's in the container.

There are three practical approaches, each adding a layer on top of the last: manual Docker containers (you manage everything), Docker Sandboxes (Docker manages the VM lifecycle), and managed orchestration with Trimo (automated git workflows, monitoring, and parallel execution on top of containers). This guide walks through all three.

Why you need isolation for autonomous Claude Code

Claude Code is a powerful coding agent. It reads files, writes code, executes shell commands, installs packages, runs tests, and commits to git. In interactive mode, you watch what it does and approve each action through a permission system. The built-in sandbox (Seatbelt on macOS, bubblewrap on Linux) restricts system calls, and command blocklists prevent dangerous operations by default.

Autonomous execution is a different story. The --dangerously-skip-permissions flag — required for unattended runs — disables the interactive permission prompts. The agent can now execute any command without asking. On your bare-metal dev machine, that means it has access to your home directory, your SSH keys, your environment variables, your running services, and your network.

Docker provides kernel-level isolation that addresses this directly:

Filesystem isolation. The container has its own root filesystem. Claude Code can only access files you explicitly mount into the container. Your home directory, credentials, and other projects are invisible.
Network isolation. The container runs in its own network namespace. You control what the agent can reach — you can restrict it to no network, specific hosts, or full internet access depending on your needs.
Process isolation. Processes inside the container cannot see or interact with processes on your host. A runaway rm -rf / inside the container destroys the container's filesystem, not yours.
Resource limits. Docker lets you cap CPU, memory, and disk usage. An agent that enters an infinite loop or tries to allocate 64GB of RAM gets stopped by the container runtime, not by crashing your machine.

This is the same isolation technology that runs every major cloud platform. It is not a permissions trick or a process-level sandbox — it uses Linux namespaces and cgroups to create a genuinely separate execution environment.

Option 1 — Manual Docker containers

The most direct approach is to build your own Docker image with Claude Code installed and run it manually. Here is a simplified example of what this looks like:

Write a Dockerfile that installs Node.js and Claude Code, copies your repo (or mounts it as a volume), and sets up the working directory.
Build the image with docker build.
Run the container with docker run, passing your Anthropic API key as an environment variable, mounting your repo, and invoking Claude Code with --dangerously-skip-permissions and your prompt.

A basic invocation might look like:

docker run --rm -v $(pwd):/workspace -e ANTHROPIC_API_KEY=sk-... my-claude-image claude --dangerously-skip-permissions --print "Implement the user settings API endpoint"

This works, and for one-off tasks it may be enough. But you quickly run into limitations:

No monitoring. You either watch the terminal output in real time or pipe it to a file and check later. With multiple runs, you are switching between terminal sessions or tailing multiple log files.
No parallel execution management. Running five agents means five terminal windows, five manual docker run commands, five separate branches to manage.
No git workflow. Claude Code can commit inside the container, but getting those commits back to your remote — on the right branch, with the right push configuration — requires additional scripting.
No pipeline continuity. If you want to iterate on the agent's output with a follow-up prompt, you need to manually set up a new container that starts from the previous container's state.
Per-project setup. Each project needs its own Dockerfile or a generic one flexible enough to handle different tech stacks, dependencies, and build tools.

For a more structured version of this approach, look at DevContainers. The DevContainer specification (used by VS Code and GitHub Codespaces) provides a standardized way to define development environments in Docker. You can define a devcontainer.json with your project's dependencies, extensions, and settings, then use it as the base for autonomous runs. This solves the per-project setup problem but still leaves monitoring, parallelism, and workflow management to you.

Option 2 — Docker Sandboxes

Docker Sandboxes is Docker's official feature for running coding agents in isolated environments. It is purpose-built for this use case and simplifies setup compared to manual Docker containers.

With Docker Sandboxes, you do not need to write a Dockerfile or manage container creation yourself. Each sandbox runs in a lightweight microVM with its own private Docker daemon — providing stronger isolation than regular containers, since the agent gets a separate kernel and cannot access your host Docker environment. You point it at a repo, specify the agent, and it creates an isolated environment.

What Docker Sandboxes provides:

MicroVM isolation. Each sandbox runs in its own lightweight VM with a separate kernel — stronger than container-level isolation. The agent cannot access your host filesystem, Docker daemon, or other running containers.
Simplified setup. No Dockerfile required. The sandbox handles environment configuration.
Session management. The sandbox manages VM start/stop and cleanup.

What Docker Sandboxes does not provide:

No orchestration dashboard. There is no UI to monitor multiple concurrent runs, view agent output in real time, or verify results across branches.
No built-in parallel execution management. You can run multiple sandboxes, but coordinating them — different branches, different prompts, different stages of review — is manual.
No git automation. Branch management and safe git handling are not part of the sandbox feature.
No pipeline continuity. Each sandbox session is independent. There is no built-in concept of a pipeline where follow-up prompts build on previous runs' commits and context.

Docker Sandboxes is a solid choice if you want strong isolation without writing Dockerfiles and you do not need workflow management on top. It occupies a middle ground between fully manual Docker setup and a managed orchestration platform.

Option 3 — Managed orchestration with Trimo

Trimo provides the full orchestration loop for running Claude Code autonomously. It handles isolation, monitoring, git workflows, parallel execution, and pipeline continuity from a single dashboard.

Here is how it works:

You install the Trimo daemon — a lightweight background process on your machine. It connects to the Trimo cloud dashboard via WebSocket.
You create a pipeline from the dashboard — specify a repo, write a prompt, and hit run.
The daemon pulls the repo, spins up a Docker container, and launches Claude Code inside it with --dangerously-skip-permissions. The agent works in a fully isolated environment with its own filesystem, network, and process space.
You monitor progress in real time from the dashboard. You see the agent's output, tool calls, and status as it works.
Work is saved automatically to a feature branch. When the run finishes, open a terminal in the container to verify the result.
You iterate by writing follow-up prompts. The next run picks up where the last one left off — same branch, same commits, full context.

What this gives you over the other approaches:

Real-time monitoring. A dashboard that shows all running pipelines, their status, output, and progress. No terminal switching.
Parallel execution. Dispatch five features simultaneously. Each gets its own container, its own branch, its own isolated environment. The dashboard shows them all.
Safe git. Work is saved continuously to a feature branch. Agents can't mess up your repo. You verify the result and merge when ready.
Pipeline continuity. Each pipeline maintains a history of runs. Follow-up prompts build on previous work. The agent sees the full branch history and knows what was done before.
Code stays local. The Trimo architecture runs agents on your machine. Source code never leaves your hardware. The cloud dashboard only sees metadata — pipeline status, run events, prompts.

The Trimo daemon manages the full container lifecycle: pulling images, creating containers, mounting repos, passing credentials securely, collecting output, and cleaning up when runs complete. You interact with the dashboard; the daemon handles the infrastructure.

Comparison

Feature	Manual Docker	Docker Sandboxes	Trimo
Isolation strength	Container	MicroVM (strongest)	Container
Setup complexity	High (Dockerfile, scripts)	Low (one command)	Low (CLI install)
Monitoring dashboard	No	No	Yes
Parallel execution	Manual	Manual	Built-in
Git automation	No	No	Yes
Pipeline continuity	No	No	Yes
Cost	Free	Free	Free tier

If isolation is your primary concern, Docker Sandboxes provides the strongest boundary (microVM with a separate kernel). If you want the lowest setup cost, Docker Sandboxes also wins — one command, no Dockerfile. If you need orchestration on top of isolation — monitoring, git automation, parallel execution, pipeline continuity — that's where Trimo adds value.

For more on how Trimo and Claude Code complement each other, see our detailed comparison. For a broader look at what autonomous coding agents are good at and where they fall short, see our guide.

Frequently asked questions

Is it safe to run Claude Code autonomously?

With Docker isolation, yes. The --dangerously-skip-permissions flag is dangerous on bare metal because it removes permission prompts while the agent has full access to your machine. Inside a container, the blast radius is limited to the container itself — separate filesystem, network, and process space. Docker Sandboxes goes further with microVM isolation (separate kernel). Either approach makes autonomous execution safe.

Do I need to pay extra?

No. You use your own Claude subscription or Anthropic API key. The orchestration layer (Docker, Docker Sandboxes, or Trimo) doesn't charge for tokens.

Can I run multiple agents at once?

Yes. Each run gets its own container — separate filesystem, network, process space. No shared ports, no shared node_modules, no conflicts. With manual Docker or Docker Sandboxes you coordinate parallel runs yourself. With Trimo, parallel pipelines are built in.

What happens if the agent makes a mistake?

The mistake is contained within the container. Your host system is unaffected. With Trimo, every change is saved to a feature branch — nothing reaches main without your explicit approval. If an agent goes off track, stop the run. The branch captures what happened, and you can start a new run with better instructions.

Does autonomous mean the agent works without any input?

Autonomous means unattended execution of a single task. You still write the prompt, review the output, and iterate. The agent handles the coding — reading files, writing code, running tests, committing — without requiring you to watch. You define the work; the agent executes it; you review the result.