How to run Claude Code autonomously: Docker isolation and orchestration

To run Claude Code autonomously, you need three things: Docker isolation to sandbox the agent's filesystem and network access, the --dangerously-skip-permissions flag to allow unattended execution without interactive permission prompts, and ideally an orchestration layer to manage container lifecycle, git workflows, and monitoring. There are three practical approaches. First, you can set up manual Docker containers — write a Dockerfile, install Claude Code, mount your repo, and run it with --dangerously-skip-permissions. This works but requires per-project setup and gives you no monitoring or workflow management. Second, you can use Docker Sandboxes, Docker's purpose-built feature for running coding agents in containers. This simplifies container lifecycle but stops at isolation — there is no dashboard, no parallel execution management, and no git automation. Third, you can use a managed orchestration tool like Trimo, which handles the full loop: dispatching Claude Code into Docker containers, monitoring progress in real time, managing git branches and commits, and supporting parallel execution and pipeline continuity from a single dashboard.

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 review diffs 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. Auto-commit, auto-push, branch management, and merge workflows 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.
Changes are auto-committed and pushed to a feature branch. Git hooks inside the container handle commit and push automatically. The branch is visible in the dashboard with full diff review.
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.
Git automation. Auto-commit on save, auto-push to remote, branch creation, and diff review are built in. The agent commits to a feature branch; you review 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	Container	MicroVM	Container
One-command setup	No	Yes	Yes
Real-time monitoring	No	No	Yes
Parallel execution	Manual	Manual	Built-in
Git auto-commit/push	No	No	Yes
Pipeline continuity	No	No	Yes
Dashboard	No	No	Yes
Cost	Free	Free	Free tier

All three approaches provide isolation for autonomous Claude Code execution. Manual Docker and Trimo use container-level isolation. Docker Sandboxes uses microVM-level isolation with private Docker daemons. The differences beyond isolation are in what happens around it: how you set up the environment, how you monitor runs, how you manage git, and how you iterate on the agent's output.

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 on when to use them.

Frequently asked questions

Is it safe to run Claude Code autonomously?

Yes, with Docker isolation. Docker containers provide kernel-level filesystem, network, and process boundaries. Claude Code running inside a container can only access the files and network you explicitly mount or expose. It cannot reach your host filesystem, credentials, or other running processes. This is the same isolation technology used in production cloud platforms. The --dangerously-skip-permissions flag is dangerous on bare metal precisely because it removes the interactive permission prompts — but inside a container, the blast radius is limited to the container itself.

Do I need to pay extra to run Claude Code autonomously?

No. You use your own Claude subscription (Claude Pro, Max, or Enterprise) or an Anthropic API key — all of which include Claude Code access. The orchestration layer — whether manual Docker, Docker Sandboxes, or Trimo — does not charge for tokens or add any markup on API usage. Trimo's free tier covers the orchestration, monitoring, and dashboard features.

Can I run multiple Claude Code agents at once?

Yes. Each autonomous run executes in its own Docker container with its own filesystem, network namespace, and process space. There are no conflicts between agents — no shared ports, no shared node_modules, no shared lock files. With manual Docker or Docker Sandboxes, you manage parallel runs yourself. With Trimo, parallel pipelines are built in — you dispatch multiple runs from the dashboard and each gets its own isolated container and git branch.

What happens if the autonomous agent makes a mistake?

With any Docker-based approach, the mistake is contained within the container. Your host system is unaffected. With Trimo specifically, every change the agent makes is auto-committed to a feature branch. Nothing reaches your main branch without your explicit approval. You review diffs in the dashboard, request changes with follow-up prompts, and merge only when satisfied. If an agent goes completely off track, you stop the run — the branch captures exactly what happened, and you can start a new run with adjusted instructions.

Does autonomous mean the agent works without any input?

Autonomous means unattended execution of a single task. You still write the prompt that defines what the agent should do, review the output when it finishes, and iterate with follow-up instructions if needed. The agent handles the coding work — reading files, writing code, running tests, fixing errors, committing changes — without requiring you to watch or interact during execution. You manage the workflow; the agent does the implementation. Think of it like delegating a well-scoped task to a junior developer: you define the work, they execute it, you review the result.