fix(doctor, test-stack-up): no Docker daemon in a cloud container is normal, not a warning - #180
Merged
Merged
Conversation
…normal, not a warning The cloud container ships the docker CLI with no daemon and the agent cannot start one. Doctor warned and printed 'sudo systemctl start docker', so sessions tried, failed and reported it as a blocker, while the mxbuild gate and mxcli run --local need no Docker. The cloud lane now says so and names the Docker-free route. Desktop lanes keep the warning plus a line that a container is optional. test-stack-up.sh names the same route instead of failing inside mxcli docker run. Field run: this cloud container (docker CLI, no daemon), plus desktop-lane, podman-only and podman-in-cloud variants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed and why (one paragraph)
The Claude Code on the web container ships the docker CLI but no running daemon, and the agent cannot start one.
bin/doctor.sh(run at scaffold and session start) warned "docker daemon is not responding … sudo systemctl start docker", and its no-runtime text said the build check needs Docker. So sessions tried to start Docker, failed, and reported "cannot start the docker daemon" as a blocker, until the user told them to usemxcli run --local. That contradictedskills/cloud-dev-environment.md, which already says no Docker is needed. Now: in the cloud lane a missing daemon is anokline saying it is normal, not to start it, the build check is exec.sh's mxbuild gate, and the app runs with./mxcli run --local(snapshot first). Desktop lanes (Docker or Podman, stopped) keep the WARN and start hint, plus one line that a container is optional. The no-runtime text no longer claims the build check needs Docker.project-bin/test-stack-up.sh, with the app down and no reachable Docker/Podman (bounded probe), stops with the Docker-free route (Studio Pro Run Locally, or./mxcli run --local) instead of failing insidemxcli docker run.Field evidence
Run in a real cloud container (docker CLI present, no daemon), same doctor, four combinations:
sudo systemctl start dockermxcli run --localtest-stack-up.shon a scratch project with the app down and no daemon: stops with "App down and no Docker/Podman reachable …" and the./mxcli run --local -p <App>.mprline;mxcli docker runis never called.Checklist
tests/wave2/test-doctor-docker-probe.shupdated (desktop cases pinCLAUDE_CODE_REMOTE=so the fixture means the same inside a cloud session; new case 2b asserts the cloud behaviour); its greps replicated by hand against the new doctor output🤖 Generated with Claude Code
https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw
Generated by Claude Code