[BUG] [P0] Claude Code Web sandbox produces Docker-incompatible projects that fail outside the sandbox!!!

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug report:

Claude Code Web currently has a serious sandbox/runtime mismatch problem for Docker-based projects.

This is not only a feature request. From a developer workflow perspective, this behaves like a bug because Claude Code Web can produce and validate code in its own sandbox, but the resulting project may fail when moved to the actual target runtime: Docker, Docker Compose, local development, a cloud IDE, VPS, staging, or production-like deployment.

For many real-world projects, the final deliverable is not just source code. The final deliverable must include a working Dockerfile, docker-compose.yml, startup scripts, environment variables, exposed ports, service dependencies, and production-like runtime behavior.

If Claude Code Web validates the project only in a simplified sandbox runtime, but the project fails in Docker, then the sandbox result is misleading.

Core issue:

The main issue is not simply that a preview URL returns 503 or 404.

503 and 404 are only symptoms.

The bigger issue is that Claude Code Web's sandbox environment is not equivalent to the final Dockerized environment. As a result, Claude Code Web can spend a full day generating or modifying a project that appears to work inside the sandbox, but when the same project is moved to local Docker, a cloud IDE, a VPS, staging, or production-like environment, it fails to run.

In my experience, around 80% of the wasted debugging time comes from Claude Code Web's Docker environment limitations, sandbox mismatch, or lack of real Docker Compose parity, not from normal application bugs.

This creates a serious reliability problem:

Claude Code Web may produce a full day's worth of code changes.
The project may look valid inside the Claude Code Web sandbox.
But once I switch to local Docker or another cloud IDE, the Dockerized version cannot run correctly.
Then I need to re-debug, rewrite, or redesign a large part of the work.

Why this is a bug:

Many real projects are not deployed by running only a local dev command such as npm run dev, pnpm dev, bun dev, or python app.py.

Many real projects are deployed through Docker, for example:

docker build ...
docker compose up ...

That means the real runtime behavior depends on Docker-specific details such as:

1. Dockerfile build steps
2. Base image behavior
3. Package manager behavior inside the image
4. Production install mode
5. Dev dependency vs production dependency separation
6. Filesystem layout
7. File permissions
8. Executable startup scripts
9. Environment variables
10. Exposed ports
11. Container startup command
12. Health checks
13. Reverse proxy behavior
14. Docker network aliases
15. Service-to-service communication
16. Database / Redis / worker containers
17. Volume mounts
18. Build cache behavior
19. Migration and seed scripts
20. Production-only runtime assumptions

These details affect architecture from the beginning.

Dockerization is not just a final packaging step.

If Claude Code Web cannot run and debug the actual Docker Compose stack during development, then the sandbox can give false confidence. The project may appear correct in Claude Code Web, but fail in the real deployment environment.

That is a bug in the development workflow because the tool is validating the wrong runtime model.

Observed behavior:

The current workflow often becomes:

1. Develop the project in Claude Code Web.
2. Make the project pass in the Claude Code Web sandbox.
3. Spend many hours iterating on code.
4. Generate or modify Dockerfile and docker-compose.yml later.
5. Move the project to local Docker, a cloud IDE, VPS, staging, or another production-like environment.
6. Discover that the project cannot run.
7. Hit Docker build errors, permission issues, startup errors, port issues, missing files, wrong install mode, dependency issues, reverse proxy issues, or service networking failures.
8. Go back and redesign or re-debug parts of the project.
9. Lose a large amount of time because the Claude Code Web sandbox was never deployment-equivalent.

This means Claude Code Web can produce a full day of work that is not directly usable outside the sandbox.

Expected behavior:

Claude Code Web should not give false confidence based on a sandbox runtime that does not match the target Docker runtime.

For Docker-based projects, the expected workflow should be:

1. Start development in Claude Code Web.
2. Build and run the real Docker Compose stack from the beginning.
3. Continuously debug against the actual deployment topology.
4. Preview services started by Docker Compose.
5. Inspect logs, ports, networks, health checks, and container status.
6. Confirm that the same project will run locally, in a cloud IDE, on a VPS, and in production-like environments.

For example, this should work reliably:

docker compose up --build

Claude Code Web should then provide a reliable way to:

1. Access the exposed application service.
2. Preview the correct container port.
3. Inspect container logs.
4. Inspect running containers.
5. Inspect Docker networks.
6. Inspect port mappings.
7. Diagnose failed health checks.
8. Distinguish application bugs from sandbox limitations.
9. Distinguish Docker Compose problems from Claude Code Web preview routing problems.
10. Distinguish container networking issues from application-level routing issues.

Impact:

This issue causes major wasted time and unreliable development output.

The most frustrating case is:

Claude Code Web spends hours generating and modifying a project.
The project appears reasonable in the sandbox.
But when the same project is moved to local Docker or another cloud IDE, it does not run.
Then most of the work must be re-debugged or redesigned around Docker behavior.

This makes Claude Code Web much less reliable for real containerized projects.

For production-style development, Docker support is not optional. It is part of the core development loop.

A modern application often includes:

1. Frontend
2. Backend
3. Database
4. Redis / queue
5. Worker process
6. Reverse proxy
7. Object storage emulator
8. Migration scripts
9. Seed scripts
10. Background jobs
11. Health checks
12. Container networking

If Claude Code Web only supports a simplified local sandbox mode, it cannot accurately validate these projects.

This can lead to incorrect architecture decisions early in the development process.

Requested fix:

Please treat this as a bug in the Claude Code Web development workflow and address the Docker sandbox/runtime mismatch.

A fix could include:

1. First-class Docker-in-Docker support inside the Claude Code Web sandbox.
2. First-class Docker Compose multi-container workflow support.
3. Reliable service port exposure from Compose services.
4. Preview URL support for services started by Docker Compose.
5. Built-in container logs, ports, networks, and health check inspection.
6. Clear diagnostics for sandbox-related Docker failures.
7. Documentation explaining supported and unsupported Docker workflows.
8. Recommended patterns for production-like Docker debugging in Claude Code Web.
9. A clear way to know whether a failure comes from the app, Docker, Docker Compose, sandbox networking, or Claude Code Web preview routing.
10. Better parity between Claude Code Web development runtime and final Docker deployment runtime.

Summary:

The main problem is not just 503 or 404.

The real problem is that Claude Code Web can validate work in a sandbox runtime that does not match the real Docker deployment runtime.

Claude Code Web can spend a full day producing code that appears to work in its sandbox, but the same project may fail in local Docker, a cloud IDE, a VPS, staging, or production-like deployment because the sandbox does not provide a real Docker Compose development environment.

For many production projects, around 80% of the wasted time comes from Docker environment mismatch and sandbox limitations, not from normal coding bugs.

Claude Code Web should treat this as a P0 bug: the sandbox should support real Docker-in-Docker / Docker Compose workflows, or at minimum clearly detect and warn when the project cannot be validated against its final Docker runtime.

What Should Happen?

full support docker in docker

Error Messages/Logs

Steps to Reproduce

Reproduction steps:

1. Open any non-trivial real-world application project in Claude Code Web.

1. Give Claude Code only one high-level prompt, for example:

"Please make this entire project production-deployable with Docker. Create or fix the Dockerfile, docker-compose.yaml, .env.example, health checks, startup commands, migrations, exposed ports, volumes, and a one-command start script. The final deliverable must be production-parity and must run with docker compose up --build. Do whatever is necessary to make the Dockerized version work end-to-end."

1. Explicitly require Claude Code Web to deliver a working Dockerfile and docker-compose.yaml, not just a local sandbox dev command.

1. Let Claude Code Web attempt to implement and debug the Dockerized setup inside its sandbox.

1. Claude Code Web may spend hours trying different fixes, editing Dockerfile, docker-compose.yaml, startup scripts, environment variables, ports, package install commands, build commands, health checks, and runtime commands.

1. Eventually, Claude Code Web often cannot fully validate the Docker Compose runtime because of Docker / Compose / sandbox limitations, unclear port exposure, preview routing, networking behavior, or runtime mismatch.

1. Move the resulting project to local Docker, another cloud IDE, a VPS, staging, or another production-like environment.

1. Run:

docker compose up --build

1. Observe that the project may fail with Docker build errors, missing files, wrong dependency mode, permission issues, startup command issues, port exposure problems, reverse proxy issues, container networking failures, health check failures, database / Redis / worker connectivity issues, or service-level 503 / 404 errors.

1. The result is that Claude Code Web may spend a full day producing changes that appear reasonable in its sandbox, but the Dockerized project still does not run in the actual target environment.

1. This is not normal application debugging. This is time wasted fighting Claude Code Web's sandbox/runtime mismatch. When the user explicitly requires a production-parity Dockerfile and docker-compose.yaml as the final deliverable, Claude Code Web should be able to run and validate that Docker Compose stack directly, or clearly detect and report that it cannot validate the target Docker runtime.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.119

Platform

Other

Operating System

Other

Terminal/Shell

Other

Additional Information

Claude Code 2.1.119
Opus 4.7 - 1M context
https://claude.ai/code/

Additional information:

Since the user has already chosen Claude Code Web, the workflow should not force the user to downgrade back to local development just to verify whether Docker / Docker Compose tasks are feasible.

That defeats the purpose of using a cloud-based coding environment.

If the final answer is still “please test Docker locally,” then Claude Code Web is not truly solving the production-development workflow. It is only moving part of the editing experience into the cloud while still pushing the most important deployment validation step back to the user's local machine.

This is wasted time and goes against the core philosophy of Claude Code Web.

Claude Code itself has moved to the web. Users should not be forced back to local development just to confirm whether a Dockerfile or docker-compose.yaml actually works.

For production-style projects, Docker and Docker Compose validation must be part of the cloud development loop, not something users have to manually re-check outside Claude Code Web after hours of sandbox work.

Otherwise, Claude Code Web creates a broken workflow:

1. Develop in Claude Code Web.
2. Trust the sandbox result.
3. Move back to local Docker or another cloud IDE.
4. Discover the Dockerized project does not run.
5. Spend more time re-debugging the same project outside Claude Code Web.

This is not just an inconvenience. It is a fundamental workflow defect.

A cloud coding product should not require users to fall back to local development for core deployment validation, especially when the final deliverable is explicitly Dockerfile + docker-compose.yaml.