[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 docker CLI should be accessible from Bash tool calls so Claude can run commands such as docker compose up, docker compose down, docker ps, docker logs <container>, and docker 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:

1. Claude Code web session starts
2. Claude runs docker compose up -d to bring up backing services
3. Claude runs the project's test suite against those live services
4. Claude interprets results and makes changes
5. 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

1. I open a Claude Code web session on a project that uses Docker Compose to run PostgreSQL, Kafka, Debezium, and a Kafka Streams processor.
2. I ask Claude to add a new domain feature and run the full test suite including integration tests.
3. Claude attempts docker compose up -d — the command fails because Docker is not available in the web environment.
4. Integration tests that rely on a live database and Kafka broker cannot run.
5. 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.