A lot of container work is investigation: which container keeps restarting, what the logs say, why the build failed, what that Compose file actually does. It’s exactly the kind of read-heavy, multi-step triage where Claude Code helps — especially once it can reach the Docker engine directly through an MCP server instead of you relaying every docker logs output by hand.
This guide covers connecting Docker to Claude Code, the workflows where it pays off, and how to keep it safe on Windows and WSL. The theme throughout is read-first: inspection and debugging are low-risk and high-value; stopping and removing things should stay deliberate.
If you’re new to MCP, the setup guide covers the basics, and MCP servers for sysadmins and DevOps places Docker among the other ops servers.
Two ways Claude Code reaches Docker
You don’t strictly need an MCP server to use Claude Code with Docker — but one makes the experience cleaner.
MCP server vs shell commands
| Docker MCP server | Structured tools — list, logs, inspect — as clean tool calls |
|---|---|
| Docker CLI in the shell | Claude runs docker commands directly when you allow it |
The MCP route gives the agent typed tools, so it reasons about containers as structured data rather than parsing CLI text. The shell route needs no extra setup — Claude just runs docker commands like you would. For ongoing container work, the server is nicer; for occasional tasks, the shell is fine.
Connecting Docker
Docker has put real effort into MCP tooling and maintains a catalog, and there are community servers as well. This space moves quickly, so the right move is to check the Docker documentation for the current supported server and install command rather than trusting a fixed snippet that may be stale.
On Windows, the practical path is Docker Desktop with WSL integration, running Claude Code inside WSL:
# inside WSL, confirm the engine is reachable
docker psIf docker ps works in your WSL shell, Claude Code running there can use Docker too — whether through a server or the CLI. The WSL install guide covers the environment if you’re not set up yet.
The debugging sweet spot
This is where it earns its keep. Start your stack, then let Claude investigate a problem end to end:
The web container keeps restarting. Look at its logs, figure out why,
and tell me what's failing before you change anything.Claude lists the containers, reads the logs of the failing one, correlates the restart with the error, and reports back — the same sequence you’d run by hand, without the context-switching. Because it’s all reads, there’s no risk in letting it run.
Other strong read-only workflows:
- Explain a Compose file. “Walk me through what this docker-compose.yml sets up and where the services depend on each other.”
- Correlate logs across services. “The API returns 500s around 14:30 — check the API and database container logs for that window.”
- Diagnose a failed build. “This image build fails at the dependency step. Read the build output and tell me the cause.”
Keeping changes deliberate
Inspection is safe; mutation needs care. When you do want Claude to act — restart a container, rebuild an image, prune something — keep it explicit and approved rather than automatic.
A few habits:
- Require approval for stop/remove/prune operations through Claude Code’s permission settings.
- Add a
PreToolUsehook that blocks the truly destructive Docker commands you never want run unattended, the same pattern as the hooks guide. - Work against local or staging stacks, not production engines.
Pair it with the rest of your setup
Docker work rarely stands alone. A few combinations that work well:
- A filesystem MCP server scoped to your Compose and Dockerfile repo, so Claude can read and edit the config it’s reasoning about. See the Docker skills for DevOps for encoding your image conventions.
- A Dockerfile skill that enforces your base images, multi-stage builds, and non-root users, so any Dockerfile Claude writes matches your standards.
- The broader sysadmin setup in Claude Code for sysadmins for the permission and config groundwork.
Docker + Claude Code checklist
- Run Claude Code in WSL with Docker Desktop integration
- Confirm docker ps works in your WSL shell first
- Check Docker's docs for the current MCP server approach
- Keep inspection read-only and let it run freely
- Require approval for stop/remove/rebuild operations
- Block destructive docker commands with a PreToolUse hook
- Add a Dockerfile skill so generated config matches your standards
Wrapping up
Claude Code is at its best with Docker when it’s investigating — reading logs, correlating failures, explaining a Compose file, diagnosing a broken build. Connect it through Docker’s current MCP tooling or just let it run CLI commands, keep inspection read-only and free, and gate anything that changes state behind approval and a guardrail hook. Run it in WSL on Windows for the smoothest experience, and pair it with a filesystem server and a Dockerfile skill so it can both reason about and improve your container config.
For the wider ops toolset, see MCP servers for sysadmins and DevOps and the sysadmin setup guide.
