Container Use
Run multiple coding agents safely in parallel inside isolated containerized environments.
Evidence shows each agent runs in an isolated container with its own git branch; git workflow provides a natural rollback path; real-time command/log visibility supports transparency; users can intervene via git checkout. But sensitive data handling is entirely unaddressed (scored 0); least privilege is only an isolation claim at README level with no file evidence of in-container permission refinement; external effects (container lifecycle, branch deletion) are asserted only; source attribution relies on the Dagger brand while the publisher is unverified; a dependency manifest exists but there is no scanning/audit/pinning policy evidence, keeping dependency security thin.
README claims compatibility with any MCP agent and gives a clear install path; CI includes build and lint workflows; internal naming is consistent (container-use/cu). But dependency availability hinges on the Dagger engine with CI pinning 'latest' (non-reproducible, drift-prone); error messages and failure handling are only indirectly claimed with no file evidence.
The target audience (developers using Claude Code, Cursor, etc.) and scenario (parallel multi-agent) are clearly described; universal compatibility and no-vendor-lock-in are emphasized; environment fit (containers) is the product core. But capability boundaries are weakly described (little beyond the experimental badge); trigger precision (when MCP tools are invoked) has no file evidence.
Documentation is well structured; install notes cover brew and curl across platforms and explain the cu alias; naming is stable; known limitations are honestly presented via the experimental badge and early-development notice; the Apache-2.0 license file is complete with copyright notice; maintenance channels (Discord, issues) are explicit. But there is no CHANGELOG or versioning record file; examples/FAQ cover only a single quick-start example; the curl|bash install path poses an unflagged supply-chain risk.
Output usability claims are concrete (URLs to view apps, git branches to review work); marginal value is clear (from babysitting one agent to parallel multi-agent); cost-benefit is reasonable (containers + git as infrastructure, Dagger ecosystem). All rest on README claims with no deeper file evidence for differentiation.
Fact/inference separation is good: the experimental status and early-development notice are explicit factual labels. But most core claims (isolation, visibility, compatibility) cannot be traced to implementation code in the provided files; cross-source corroboration is limited to self-declarations and badges (Awesome list, Discord); independent verification evidence is absent.
- The recommended curl | bash install script carries supply-chain risk; enterprise environments should prefer brew or build from source with hash verification.
- CI workflows use the Dagger engine with version 'latest', making builds non-reproducible and prone to drift from local environments.
- Sensitive data (env vars, secrets) handling inside containers is entirely undocumented; agents may access host-repository credentials in containers — audit before use.
- The project self-labels as experimental/early-stage; interfaces and behavior may change without notice — not suitable for production-critical paths without testing.
- Publisher identity is unverified; attribution rests solely on in-repo claims.
What does this agent do, and when should you use it?
Container Use is an open-source MCP server and CLI tool from the Dagger team that gives coding agents containerized development environments. Each agent works in a fresh container on its own git branch, so multiple agents can run concurrently without conflicts. Users get real-time visibility into the complete command history and logs of what each agent actually did, and can drop into any agent's terminal to intervene. It integrates through the standard MCP protocol, with documented usage alongside Claude Code and Cursor, and works with any agent, model, or infrastructure without vendor lock-in. The project is experimental and actively evolving, so stability should be weighed before adoption.
Container Use runs as an MCP server via container-use stdio (shortcut cu stdio). When an agent receives a task, it provisions an isolated environment consisting of a fresh container and a dedicated git branch; the agent executes commands, builds, and runs applications there (e.g. a Flask app), returning URLs for the user to inspect the result. You can review any agent's work with standard git checkout <branch_name>, inspect full command history and logs, or enter the agent's terminal to take over. Installation is via Homebrew (brew install dagger/tap/container-use) or the official install script, followed by registering the server with claude mcp add container-use -- container-use stdio and optionally appending the official agent rules file.
- A Claude Code developer wants several agents tackling different tasks simultaneously without overwriting each other's files or dependencies.
- A team auditing agent output needs git branches plus complete command logs to verify what the agent actually executed.
- A developer wants to trial multiple implementation approaches in parallel with near-zero discard cost for failed attempts.
- A Cursor or other MCP-compatible tool user wants to give agents a containerized runtime with their preferred dependency stack.
- An engineer needs to intervene directly in a stuck agent's terminal to inspect state and take control.
What are this agent's strengths and limitations?
- Each agent gets its own container plus its own git branch, enabling true conflict-free parallel agent work.
- Complete command history and logs give an auditable record of actual agent behavior, not just claimed actions.
- Review happens through standard git workflow (
git checkout <branch_name>) with no new review tooling to learn. - Open MCP protocol integration means any agent, model, or infrastructure works — no vendor lock-in.
- The project is explicitly marked experimental and in early development; behavior may change without notice.
- It requires a local containerized runtime, an extra setup burden on restricted or container-less machines.
- Only MCP-compatible agent tools are supported; non-MCP editors or workflows need separate adaptation.
- The README provides no performance benchmarks, security isolation guarantees, or multi-user deployment evidence, so these must be validated independently.
How do you install or deploy this agent?
macOS (recommended): brew install dagger/tap/container-use. All platforms: curl -fsSL https://raw.githubusercontent.com/dagger/container-use/main/install.sh | bash. The tool is powered by Dagger, with container runtime needs handled by the tool; see container-use.com for full prerequisites.
How do you use this agent?
- cd into your repository. 2. Register the MCP server:
claude mcp add container-use -- container-use stdio. 3. (Optional) add agent rules:curl https://raw.githubusercontent.com/dagger/container-use/main/rules/agent.md >> CLAUDE.md. 4. Give your agent a task, e.g. "Create a hello world app in python using flask". The agent works in an isolated environment and returns URLs to view the app.cuis an equivalent shortcut forcontainer-use.