Fix devcontainer startup: resolve Docker context + propagate feature containerEnv - #31
Merged
Conversation
The Docker SDK's FromEnv only honors DOCKER_HOST and ignores the active docker CLI context, so human could not reach the engine out-of-the-box on colima/OrbStack/Rancher/Docker-Desktop/Podman, where the socket/pipe is exposed via a context rather than DOCKER_HOST. The failure surfaced only as the opaque "starting agent container". Add internal/dockerhost.Resolve, a shared cross-platform resolver mirroring the docker CLI context precedence (explicit DOCKER_HOST/DOCKER_CONTEXT win, else config.json currentContext, else the platform default), handling unix sockets and Windows named pipes. NewDockerClient and NewEngineDockerClient both layer the resolved host onto FromEnv via the one resolver so they never diverge, and Docker connection failures now surface an actionable error naming the active context and attempted endpoint. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A devcontainer feature's containerEnv (FeatureMeta.ContainerEnv) was parsed
but never applied, so the node feature's PATH/NVM additions never reached the
features installed after it nor the committed image. A dependent feature such
as ghcr.io/anthropics/devcontainer-features/claude-code then could not find
node/npm and its install.sh failed, surfacing only as "starting agent
container".
InstallFeatures now accumulates each feature's containerEnv, expanding ${VAR}
against the container's real base environment, feeds it to the install.sh of
later features, and returns it so buildWithFeatures bakes it into the image
via an extended ContainerCommit (sorted ENV directives). The puller is made
injectable for testing. execInContainer is refactored to a shared execCapture
core and now carries the command's stdout tail in the failure error, since
feature scripts print their fatal reason there.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
Two independent bugs each blocked
human agent startfrom launching a devcontainer. Both are fixed here as separate, atomic commits.[HUM-122] Resolve active Docker context in both engine clients (
462fff4)The Docker SDK's
FromEnvonly honorsDOCKER_HOSTand ignores the active docker CLI context, so human couldn't reach the engine out-of-the-box on colima / OrbStack / Rancher / Docker-Desktop / Podman, where the socket/pipe is exposed via a context. The failure surfaced only as the opaquestarting agent container.internal/dockerhost.Resolve: a shared, cross-platform resolver mirroring the docker CLI's context precedence (explicitDOCKER_HOST/DOCKER_CONTEXTwin →config.jsoncurrentContext → platform default). Handles unix sockets and Windows named pipes.NewDockerClientandNewEngineDockerClientboth layer the resolved host ontoFromEnvvia the one resolver (no divergence).github.com/docker/clipromoted to a direct dependency.[HUM-125] Propagate feature containerEnv to later installs and image (
74b2eb2)A devcontainer feature's
containerEnv(FeatureMeta.ContainerEnv) was parsed but never applied, so the node feature's PATH/NVM additions never reached the features installed after it nor the committed image.claude-codethen couldn't find node/npm and itsinstall.shfailed — again surfacing only asstarting agent container. (Distinct from the already-mergedinstallsAfterordering fix, HUM-121.)InstallFeaturesaccumulates each feature'scontainerEnv, expands${VAR}against the container's real base env, feeds it to later features'install.sh, and returns it.ContainerCommitextended to bake the accumulated env into the image as sortedENVdirectives;ImageBuilder.Pullermade injectable for tests.execInContainerrefactored to a sharedexecCapturecore; the "exec failed" error now carries the command's stdout tail (where feature scripts print their fatal reason).Testing
make checkgreen (lint 0 issues, govulncheck/gitleaks clean); total coverage 81.7%. One unrelated flaky test (internal/chrome/TestMcpTranslator_SubprocessExit, untouched package, subprocess timing) failed once and passes on retry.DOCKER_HOST/DOCKER_CONTEXTset/unset, malformed store); containerEnv propagation to later installs; containerEnv baked into the commit;${VAR}expansion; both engine constructors apply the resolved host.human agent starton colima/macOS: all four features install (incl. claude-code + treehouse/human),Image cached,Devcontainer running/Agent started, containerUp. Runtime check: the cached image's ENV resolvesnode v22.23.0,go,npmdirectly.🤖 Generated with Claude Code