Integrating Container-Use in WSL for Agentic Development
Context
Model Context Protocol (MCP) implementations are becoming increasingly prevalent, enabling developers and systems to interact with multiple services using Large Language Models. For several months, Visual Studio Code has supported MCP integration in GitHub Copilot as a preview feature.
In combination with agentic workflows, LLM solutions can not only provide coding assistance but also autonomously access services, acting on behalf of users to fetch and update documentation, review pull requests, start CI/CD pipelines, and automate other tasks typically performed by software engineers.
What is container-use?
While this shift toward agentic, MCP-integrated workflows is happening, Dagger.io is pivoting toward solutions that enable safe usage of GenAI using their container-based graph and sandboxing solution.
These efforts culminated in the release of container-use. This solution enables multiple IDEs and development tools to leverage containers and Git, allowing agents to work toward solutions without interfering with each other or the engineer working on the same codebase. Under the hood, Dagger spawns and controls containers that isolate coding agent actions within separate runtime environments and Git branches.
Inspired by this release, the upcoming book by Gene Kim and Steve Yegge, and the preview release of Claude Sonnet 4 in Visual Studio Code, I wanted to explore this approach.
Problem
The documented implementation scenario does not cover Windows-based systems, as Dagger has not released a Windows binary and the tool cannot be compiled on Windows.
Therefore, I needed to adapt the scenario to integrate the required binary from WSL instead.
Typically, MCP providers also deliver Docker-based implementations of their servers, but this approach cannot be used here because container-use itself relies on Dagger (and Docker transitively).
Solution Overview
Description
The following diagram presents the relationships between the different actors and systems:
Throughout this post, the access of the MCP server through WSL deserves special attention, as most guides only cover container-based MCP servers when system requirements need to be abstracted.
Prerequisites
Required Skills and Knowledge:
- Basic familiarity with WSL and Docker
- Understanding of MCP concepts in Visual Studio Code
Required Tools:
- Access to GitHub Preview Features
- Claude Sonnet 4 in GitHub Copilot
- MCP functionality in GitHub Copilot
- Windows Subsystem for Linux distribution of choice
- Docker Desktop or another container runtime that can be integrated with WSL
- Latest release of Visual Studio Code
Setup
Installing container-use
First, I installed container-use in my primary WSL distribution. I noted the installation location for later reference:
techdecline@host:~$ curl -fsSL https://raw.githubusercontent.com/dagger/container-use/main/install.sh | bash
ℹ️ Starting container-use installation...
ℹ️ Checking dependencies...
ℹ️ Detected platform: linux/amd64
ℹ️ Latest version: v0.0.5
ℹ️ Installation directory: /home/techdecline/.local/bin
ℹ️ Installation will continue...
ℹ️ Downloading cu v0.0.5 for linux/amd64...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 5537k 100 5537k 0 0 578k 0 0:00:09 0:00:09 --:--:-- 916k
ℹ️ Verifying checksum...
✅ Checksum verified
ℹ️ Extracting archive...
ℹ️ Installing to /home/techdecline/.local/bin...
✅ cu installed successfully!
✅ Installation complete!
✅ cu is ready to use!
ℹ️ Run 'cu --help' to get started
techdecline@host:~$ which cu
/home/techdecline/.local/bin/cu
Configuring the MCP Server in Visual Studio Code
After installing the tool, I integrated it into my Visual Studio Code user settings by opening settings.json.
Within the mcp block, I added a configuration for container-use that calls the required binary using the Windows Subsystem for Linux:
"mcp": {
"servers": {
"container-use": {
"type": "stdio",
"command": "wsl",
"args": [
"-e",
"/home/techdecline/.local/bin/cu",
"stdio"
]
}
}
}
This configuration uses a useful feature of WSL that allows you to run Linux commands from Windows. This approach is necessary because Visual Studio Code runs on Windows even when using the WSL extension.
After saving the configuration, you should be able to start the MCP server.
Demonstrating container-use
Creating a Clean Repository
From the WSL terminal, I created a clean folder, initialized a new Git repository, and opened it in Visual Studio Code:
mkdir cu-demo
cd cu-demo/
git init
touch README.md
git add . && git commit -m "init"
code .
Preparing the Prompt
After opening Visual Studio Code and the Copilot extension, I ensured that the MCP server for cu was running and initiated the following prompt:
use #container-use to create a new python fast-api application called air-dnd
(a pun on Airbnb and dungeons and dragons) that allows users to browse both
different analog role-playing games and playing locations. Use strict type
checking with pydantic, ruff formatting and linting, and create appropriate
test cases.
Note: You may need to authorize the MCP server during the first use.
Monitoring the Agent's Progress
While the process runs, you can monitor the agent's work using cu watch from the WSL terminal or the terminal within Visual Studio Code:
Every 1.0s: git log --color=always --remotes=container-use --oneline --graph --decorate
* e091f4b (container-use/air-dnd-app/star-warthog) Write models.py
* 01f8ec6 Write README.md
* eba78a5 Write pyproject.toml
* 416fe13 Write requirements.txt
* 9840e9a Update environment air-dnd-app
* 3e84ab5 Init env air-dnd-app
* 25560f2 (HEAD -> master, container-use/master)
As shown, the agent actively uses Git commits to create snapshots of its actions for better auditing.
Inspecting the Results
When the agent completes its work, you can open a terminal within the environment using:
cu terminal <environment-name>
This command spawns a terminal within the container that Dagger used for the environment. Within this terminal, you can launch the application, run tests, and browse through files as well as the Git history.
Merging Results to the Working Directory
After validation, you can merge the agent's work into your current working directory:
cu merge <environment-name>
This will apply all the commits from the environment on your current working branch. This allows both for following up on the changes as well as squashing or reorganizing them if necessary.
Results
This demonstration shows how combining container-use from WSL with Claude Sonnet 4 enables sandboxed agentic workflows from Visual Studio Code on Windows, delivering fast feedback and improving developer productivity.
Since the results vary due to the non-deterministic nature of LLM applications, the specific code generated for the demo application is less relevant than the workflow itself.
Conclusion
Since discovering Dagger.io, I have been enthusiastic about using the container primitive to improve workflows across different domains of software engineering. While I continue to struggle with delivering consistent results in CI environments (due to caching issues, Python SDK overhead, and primarily my own knowledge gaps), I envision a world where containerized agentic workflows enable greater confidence and easier parallelization of work.
Enabling this vision in Visual Studio Code on Windows certainly broadens the potential audience, which I consider beneficial. Integrating additional MCP servers like Atlassian Jira and Confluence, or CI providers like GitHub, could further extend the impact of LLM-based developer tooling.
One limitation I still face is that this solution cannot be used in conjunction with Dev Containers due to path inconsistencies. However, this is a trade-off I am willing to accept, especially given that there are lower-overhead solutions for managing dependencies, such as mise-en-place or uv in the Python ecosystem.