Repository navigation
Run devlaunch from inside the devlaunch devcontainer #326
Description
Destination
pixi run aid <repo> inside the devlaunch devcontainer opens a real nested workspace cleanly — no docker errors on the way up. Done looks like: a workspace boots via docker-in-docker from inside the container, or the failure is understood and documented as unsupported with a clear refusal.
Notes
Single-ticket map: known work, no fanning. Filed as follow-up from testing the interactive aid prompt (PR for that feature is separate); the interactive flow itself worked in-container, the nested devpod up hit docker load errors. The devcontainer carries docker-in-docker (docker 29.7.2 at time of filing), the project env's devpod with the docker provider configured as default, and a forwarded GH_TOKEN.
Activity
blooop commentedon Aug 22, 2026
breadcrumb: claiming and starting build. Restating the contract: from inside the devlaunch devcontainer, a nested
pixi run dl/aid <repo>must either open a workspace cleanly through docker-in-docker, or refuse clearly with the limitation documented. The ticket names no seams; first step is reproducing the nested-launch docker failure to understand it, then I will post the seam I intend to test before writing any test.blooop commentedon Aug 22, 2026
breadcrumb: failure reproduced and understood. A nested launch fails when the target's devcontainer bind-mounts an individual file (the claude-code feature's .claude.json) whose host original has been atomically replaced since the outer container was created — the outer container's mount then points at a deleted inode, which the outer container can still read but the inner docker daemon refuses as a bind source (runc: 'no such file or directory'). Repos that mount the whole ~/.claude directory launch fine nested; devlaunch's own devcontainer fails within minutes of the host running claude, because claude rewrites .claude.json by rename constantly. Manually detaching the stale mount and rewriting the same bytes as a plain file lets the nested launch proceed. Seam, pre-agreed here: the feature's host-side hook run against a prepared HOME — the same seam the existing config-protection tests drive. New tests assert the hook replaces a deleted-inode file mount with a plain file carrying the same bytes and mode, and touches nothing when the HOME holds ordinary files.
blooop commentedon Aug 22, 2026
breadcrumb: PR #335 opened. The slice: the claude-code feature's host-side hook now detaches any of its file mounts whose backing inode the host has replaced (Claude rewriting .claude.json by rename was the trigger) and leaves an ordinary file with the same bytes and mode, which is what lets a Docker daemon inside the container bind it — so a nested launch from the devlaunch devcontainer now opens a real workspace where it used to die at the mount. Verified against the staged failure state end-to-end; live mounts are provably left connected.
fix: a stale agent.sock mount still blocked the nested create #326 he…