# dagger/container-use: containerized environments for coding agents > Container Use is an MCP server and CLI that gives each coding agent its own container and git branch. It is experimental, Apache-2.0, and built on Dagger. **dagger/container-use** — Development environments for coding agents. Enable multiple agents to work safely and independently with your preferred stack. - Repository: https://github.com/dagger/container-use - Website: https://container-use.com - Stars: 4,052 · Forks: 209 - Language: Go - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/dagger-container-use ## The problem Container Use targets: one agent at a time A coding agent that edits files directly in your working tree creates two problems. The first is contention: two agents editing the same checkout will overwrite each other, so you run one and wait. The second is trust: you see the agent's summary of what it did, not the commands it ran. Container Use is aimed at engineers who already drive an MCP-compatible agent and want to run several of them against the same repository without serialising the work. The README frames the change as going "from babysitting one agent at a time to enabling multiple agents to work safely and independently with your preferred stack." Each agent gets a fresh container in its own git branch, so a failed experiment is discarded by deleting a branch rather than by cleaning up a dirty tree. The project is a Go binary that acts as an MCP server, distributed as a CLI. It is not an agent and not a model. It sits between your agent and the work, and it is powered by Dagger, which is what actually builds and runs the containers. ## How the MCP server, git branches and Dagger fit together The architecture is visible in the repository layout and the dependency list. The top level holds `mcpserver/`, `environment/`, `repository/`, `cmd/` and `rules/`, and `go.mod` requires `dagger.io/dagger v0.21.8` alongside `github.com/mark3labs/mcp-go v0.57.0`. That pairing describes the mechanism: the process speaks the Model Context Protocol to your agent on one side and drives Dagger on the other. Your agent calls tools over stdio instead of running shell commands in your checkout. Each environment is a container on its own git branch, and the README describes the review path as a standard git workflow: run `git checkout ` to inspect what an agent produced. The branch is the unit of isolation and the unit of review at the same time, which is the design choice worth noticing. Nothing is merged automatically; the container's output lands on a branch and waits for you. The README also claims complete command history and logs, so the record is of what the agent executed rather than what it reported. It further describes dropping into an agent's terminal to inspect state and take over. The repository contains an `examples/` directory with `hello_world.md`, `parallel.md`, `security.md` and `services.md`, which is a reasonable place to look for worked scenarios before writing your own agent rules. ## Installing Container Use and registering it with Claude Code Two install paths are documented. Homebrew is described as the macOS recommendation; the shell installer covers all platforms. ```bash # macOS (recommended) brew install dagger/tap/container-use # All platforms curl -fsSL https://raw.githubusercontent.com/dagger/container-use/main/install.sh | bash ``` The setup step is the same for every agent: add `container-use stdio` as an MCP server. The README gives the Claude Code form, run from inside the repository you want the agents to work on. ```bash cd /path/to/repository claude mcp add container-use -- container-use stdio ``` Optionally you can append the project's agent rules to your `CLAUDE.md`. The README shows a curl that appends `rules/agent.md` to that file. The README notes the command is also available as `cu`, and that `container-use stdio` and `cu stdio` behave identically. For the first real use, the README's own prompt is deliberately small: ask the agent to "Create a hello world app in python using flask". According to the README, the agent works in an isolated environment and returns URLs for viewing the app and exploring the code. The corresponding walkthrough lives at `examples/hello_world.md`. If the agent returns nothing, the first thing to check is whether the MCP server registered, since the setup is the same for every agent and a missing registration looks like an agent that simply ignored the request. ## Where Container Use is the wrong tool The README carries its own warning: the project is "in early development and actively evolving", and the badge marks stability as experimental. Treat the interface as moving. The last release listed is v0.4.2 from 2025-08-19, and the repository's most recent push is 2026-09-21, so work continues, but a 0.x line with three releases in three weeks during July and August 2025 is not a stable contract. The harder constraint is git. Isolation is expressed as a branch, and the review workflow is `git checkout `. In a repository where a branch per agent is impractical, or in a project that is not under git at all, the central mechanism has nothing to attach to. There is also a cost the README does not discuss. Every agent environment is a container built through Dagger, so you are adding a container build to each task and taking on the Dagger dependency in your toolchain. The README does not document what happens to a container when an agent crashes, whether environments are garbage collected, or how to roll an environment back to an earlier state. Those gaps matter more than the feature list if you plan to run agents unattended. ## Container Use compared with plain agent sandboxing The obvious alternative is the sandboxing your agent already ships with, or a hand-rolled setup where you copy the repository into a temporary directory or a container and run the agent there. That approach isolates the filesystem, and if you script it yourself you can also isolate the network. The difference is what happens after the agent finishes. A copied directory or an ad hoc container leaves you with an artefact you have to diff by hand and a cleanup step you have to remember. Container Use puts the result on a git branch, so the diff, the history and the discard path are the tools you already use. The README's framing of "experiment safely, discard failures instantly" only works because the branch is the container's output. The second difference is observability. A manual sandbox records whatever you thought to redirect. Container Use presents itself as an MCP server, so the command history arrives through the protocol alongside the work, and the README's claim is that you see what agents actually did rather than what they claim. If you already have a sandboxing wrapper you trust, the branch-per-agent model is the part worth copying; the Dagger dependency is the part to weigh. ## Maintenance, releases and the Apache-2.0 licence The repository is not archived, and the most recent push is 2026-09-21. The release cadence visible in the repository is three versions in the space of about three weeks in mid-2025 (v0.4.0 on 2025-07-31, v0.4.1 on 2025-08-01, v0.4.2 on 2025-08-19), which suggests fixes shipped quickly during that period. The README does not describe an upgrade path, a compatibility policy or a deprecation process, so pinning a version and reading the release notes before moving is the only defensible routine. Licensing is Apache-2.0, stated in the README badge and in the `LICENSE` file at the repository root. That is a permissive licence with an explicit patent grant and a requirement to preserve notices. It says nothing about the Dagger dependency's own terms, and the README does not describe them, so check that separately if your organisation reviews transitive licences. This is not legal advice. Because the tool drives containers, the operational cost sits partly outside the binary: image pulls, build time and whatever your Dagger setup needs. The README does not quantify any of it. ## Conclusion Adopt Container Use if you already run Claude Code, Cursor, Goose or another MCP-compatible agent on a git repository and want each agent's work isolated on its own branch, with the command history visible. Do not adopt it if you need a stable interface, since the README labels the project experimental, or if you work outside git. Before rolling it out, verify the MCP registration with `claude mcp add container-use -- container-use stdio` and confirm your agent surfaces the URLs the README says it returns. ## FAQ ### What is dagger/container-use? It is an open-source MCP server that works as a CLI tool, giving each coding agent a fresh container in its own git branch. It is powered by Dagger and licensed under Apache-2.0. ### How do I set up container-use with an MCP-compatible agent? Add `container-use stdio` as an MCP server; the README shows `claude mcp add container-use -- container-use stdio` run from inside the repository. The README states the setup is the same for every agent, and points to a quickstart page for Cursor, Goose and VSCode. ### Is there an alternative to container-use? The alternative described in the README's own terms is running the agent directly in your checkout, or in a sandbox you script yourself. A manual sandbox isolates the filesystem, but Container Use puts each agent's output on a git branch, so review and discard use standard git commands. ## Sources - [dagger/container-use on GitHub](https://github.com/dagger/container-use) - [License: Apache-2.0](https://github.com/dagger/container-use/blob/main/LICENSE) - [Project website](https://container-use.com) - [README](https://github.com/dagger/container-use/blob/main/README.md) - [Releases](https://github.com/dagger/container-use/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dagger-container-use