[FEATURE] Docker support in Claude Code web environment
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
When using Claude Code in the web (cloud) environment, Docker is not available as an executable tool. This is a significant limitation for projects that rely on Docker to manage services, run integration tests, or replicate production-like environments locally.
For example, in projects that use docker-compose to orchestrate services — such as databases (PostgreSQL), message brokers (Kafka), CDC connectors (Debezium), schema registries, and stream processors — there is no way to start, stop, rebuild, or inspect those services from within a Claude Code web session. This means Claude Code cannot:
- Run my test suit of integration tests after adding or modifying the source code of my project
- Start dependent services before running integration tests
- Verify that container definitions (
docker-compose.yml,Dockerfile) are correct - Inspect running containers to diagnose infrastructure issues
- Rebuild images after dependency or configuration changes
The current workaround requires the developers to manually manage Docker on their local machine in a separate terminal, context-switching away from the Claude Code session and breaking the integrated development flow.
Proposed Solution
Make the docker and docker compose CLI tools available and executable within the Claude Code web environment. Specifically:
- The
dockerCLI should be accessible fromBashtool calls so Claude can run commands such asdocker compose up,docker compose down,docker ps,docker logs <container>, anddocker compose up --build. - Container networking should be accessible so that services started via Docker are reachable by the backend under test (e.g., a PostgreSQL container on port 5432).
- Session-scoped lifecycle: containers started during a session should be cleaned up automatically when the session ends, to avoid resource leaks.
The ideal user experience:
- Claude Code web session starts
- Claude runs
docker compose up -dto bring up backing services - Claude runs the project's test suite against those live services
- Claude interprets results and makes changes
- On session end, containers are stopped and removed automatically
Alternative Solutions
- Local Claude Code CLI — running Claude Code locally gives full access to the host Docker daemon. This works but loses the convenience and accessibility of the web interface.
- Manual coordination — the developer keeps services running in a separate terminal and tells Claude to assume they are available. Error-prone and breaks the self-contained nature of a session.
- testcontainers managed by pytest — some test frameworks can spin up Docker containers programmatically within tests. This partially mitigates the problem for integration tests but still requires Docker to be present in the execution environment.
Priority
High - Significant impact on productivity
Feature Category
CLI commands and flags
Use Case Example
- I open a Claude Code web session on a project that uses Docker Compose to run PostgreSQL, Kafka, Debezium, and a Kafka Streams processor.
- I ask Claude to add a new domain feature and run the full test suite including integration tests.
- Claude attempts
docker compose up -d— the command fails because Docker is not available in the web environment. - Integration tests that rely on a live database and Kafka broker cannot run.
- Claude is unable to verify the implementation end-to-end and must ask the developer to manually start services and re-run tests.
With Docker available, Claude could complete the entire workflow autonomously: start services, run tests, observe failures, fix code, and confirm correctness — all within a single uninterrupted session.
Additional Context
This limitation was identified while working on a private project that uses the following Docker Compose service topology:
| Service | Port | Purpose |
|---------|------|---------|
| backend | 8000 | FastAPI application |
| database | 5432 | PostgreSQL 16 (Debezium image for CDC) |
| kafka | 9092 | Message broker |
| schema-registry | 8085 | AVRO schema management |
| debezium | 8083 | CDC connector |
| kstream | 8084 | Kafka Streams processor node |
Without Docker, Claude Code can only run unit tests (which use in-memory fakes). It cannot exercise the full event-driven pipeline or validate any infrastructure configuration changes.
A sandboxed Docker-in-Docker (DinD) or rootless container runtime (e.g., Podman) would be an acceptable implementation approach if full Docker daemon access raises security concerns.
5 Comments
With the help of Claude Code we got it working. Claude Code generated some instructions how to set it up:
Docker & Testcontainers in Constrained Environments
Problem
Claude Code web sessions (and similar constrained CI environments) run on Linux kernel 4.4.0 in a containerized environment where Docker is not pre-installed. This makes it impossible to use Testcontainers for integration testing (MongoDB, Redis, etc.) without manual setup.
Key Constraints & Workarounds
| Constraint | Error Message | Workaround |
|---|---|---|
| Kernel 4.4.0 |
failed to convert whiteout file: operation not permitted| Use--storage-driver=vfsinstead ofoverlay2|| No iptables/ip6tables |
failed to advertise addresses: operation not supported| Use--iptables=false --ip6tables=false|| No bridge networking |
network bridge not found/ Testcontainers fails | Use--network hostand start containers via Docker CLI directly || Stale
docker0interface |existing interface docker0 is not a bridge| Delete withip link delete docker0before starting dockerd |Solution: Automated Docker Setup in Session Start Hook
Add Docker setup to your session start hook (e.g.
.claude/hooks/session-start.sh):Why Testcontainers Won't Work Directly
Testcontainers relies on Docker bridge networking to map random host ports to container ports. Without bridge networking (which requires iptables kernel support), Testcontainers cannot:
The Testcontainers library's
UnixSocketStrategyandConfigurationStrategyboth fail because they assume bridge networking is available.Workaround: Bypass Testcontainers with Host Networking
Instead of using Testcontainers, start containers manually with
--network hostand fixed ports, then write config files that your test setup reads.Step 1: Start Containers
Step 2: Write Container Info Files
Step 3: Update Jest Global Setup
In your Jest
global-setup.js, add an early return when.container-info.jsonexists:Step 4: Update Jest Global Teardown
Don't delete
.container-info.jsonwhen using pre-existing containers:Database Cleanup for Test Isolation
When reusing persistent containers, you need to clean up between test runs:
MongoDB
Redis
Redis doesn't typically need cleanup between runs since Testcontainers tests usually use isolated key prefixes, but you can flush if needed:
Performance Notes
vfsstorage driver is significantly slower thanoverlay2for image pulls and container creation. Image pulls that take 5s with overlay2 may take 30-60s with vfs.Troubleshooting
Docker daemon won't start
Container starts but tests can't connect
Testcontainers error: "Could not find a working container runtime strategy"
This means Testcontainers can't use Docker at all. Either Docker isn't running or bridge networking isn't available. Use the manual container approach described above.
Here is what Claude Code added to
session-start.sh:+1
Thank you @ja-ka for the workaround. I asked Claude to implement and similar solution, but adapted for my project. I have tested for a few weeks and it works.
I am going to post my scripts here just in case anyone is using Postgres and Python, like me.
This how my
start-session.shlook like:Then, in
.claude/settings.jsonThe hook is registered like this:And finally, my
conftest.pyneeds some special wire-up to distinguish a local session Docker from a Web environment one.I hope this help. 🚀
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.