Repository navigation
recreate/restart fail on a relative initializeCommand #87
Description
Destination
dl <repo> recreate and dl <repo> restart work on a repo whose devcontainer.json has a relative initializeCommand, instead of dying before the container is touched.
Observed on the host, against blooop/devlaunch itself:
$ dl blooop/devlaunch recreate -- "claude --version"
info Running initializeCommand from devcontainer.json: 'sh -c .devcontainer/claude-code/init-host.sh'
error sh: 1: .devcontainer/claude-code/init-host.sh: not found
fatal run agent command failed: exit status 1
restart fails identically. Creating a fresh workspace runs the same hook successfully, so this is specific to the paths that act on an already-existing workspace.
Done looks like: both commands complete on blooop/devlaunch from any working directory, and the hook runs.
Notes
Single-ticket map: known work, no fanning.
Ruled out already, so nobody re-treads it:
- Not a missing file.
.devcontainer/claude-code/init-host.shhas existed since the initial commit (195bb3d) and is mode100755onmain.initializeCommandwas added in that same commit, so no checkout of this repo has one without the other. - Not a stale clone. Same reason — there is no commit where the reference exists but the script doesn't.
- Not the
-- <cmd>suffix.recreateis dispatched atdl.py:1219before shell-command parsing; the trailing-- "claude --version"is ignored, not mis-parsed.
Leading hypothesis, explicitly unconfirmed: the hook path is relative, so it resolves against devpod's working directory, and run_devpod (dl.py:691) never sets cwd — devpod inherits whatever directory dl was launched from (~ in the report, which has no .devcontainer). Creating a workspace works because devpod is given a source path to anchor on; recreate/restart resolve an existing workspace by id, and devpod up --help shows source is optional for that. Verify before building on it — if the real cause is elsewhere, this stops being single-ticket work and hands off to /wayfinder.
No environment reachable from this session can reproduce it: the devcontainer has devpod v0.26.1 but no Docker daemon (PR #69 would add one, still open). Final confirmation is the human's, on the host.
Activity
blooop commentedon Aug 7, 2026
breadcrumb: #88 stopped at its confirm gate without implementing. The leading hypothesis this map recorded — relative hook path resolving against dl's inherited working directory — is disproven by direct observation of devpod v0.26.1: it chdirs into the workspace's recorded local source folder before running
initializeCommand, identically whether the workspace is addressed by path (create) or by id with--recreate. The launcher's directory never reaches the hook.The reported error was reproduced verbatim by a different mechanism: source folder present and its
devcontainer.jsonintact, but the hook file absent from that folder.Also corrected: the existing-workspace path does not hand devpod a clone path — it hands the bare workspace id, and it skips the clone manager entirely, so nothing verifies the clone before devpod is asked to rebuild from it.
Per this map's own escape clause, this is no longer single-ticket work. Full detail and the two host-side checks that would re-scope it are in #88.
blooop commentedon Aug 7, 2026
breadcrumb: map's escape clause fired — the leading hypothesis was disproven at the confirm gate (details on #88). This is no longer single-ticket known work; it re-scopes once the host check identifies the real cause. Map stays open, ticket #88 parked.
blooop commentedon Aug 7, 2026
Cause found — on-host, observed
Not a working-directory problem, and not a hook-resolution problem. PR #81 (
5db5c42,3875246) changed the workspace id and clone-directory leaf from<branch>to<repo>-<branch>-<syllable-suffix>, migrateddl'smetadata.json, and left devpod's own workspace records pointing at the old paths.For
devlaunch-mainon this host:metadata.json→…/devlaunch/devlaunch-main-zovomobo— real checkout,init-host.shpresentworkspace.json→…/devlaunch/main— 1 file, no.gitThe old checkout is gone, so on recreate devpod reconstitutes the source folder from its cached
workspace_result.json— which holds exactly{"name":"devlaunch","initializeCommand":{"":[".devcontainer/claude-code/init-host.sh"]}}, byte-for-byte the shape of the lone stub left on disk. devpod chdirs there and runs the hook;init-host.shis repo content, not devcontainer config, so it was never restored. Hencenot found.36 of 39 workspaces on this host are broken the same way. Only three are healthy — all created after the scheme change. That is why fresh create works and recreate/restart don't.
Correction to the "Ruled out already" list above
"Not a stale clone" was right for the wrong reason. There is indeed no commit where the
initializeCommandreference exists without the script — but the folder devpod runs in is not a checkout at all, it is a config-only stub devpod wrote from its own cache. Content-level reasoning could not see this case.The leading hypothesis in Notes is also retracted: devpod chdirs into the recorded source folder before running
initializeCommand, identically whether the workspace is addressed by path or by id, sodl's working directory never reaches the hook. Verified against devpod v0.26.1 directly.This stays single-ticket work. #88 is re-scoped to the real fix: persist
devpod_workspace_id(declared atworktree/models.py:71, currently never assigned) and address devpod by the stored id rather than a re-derived one, plus a one-time reconciliation for the existing orphans. Note that PR #86 (Release 0.0.10) is what ships PR #81, so the migration wants to land before or with it.blooop commentedon Aug 8, 2026
Narrowing datum from a neighbouring map (#93's prototype ticket, #94).
While building this repo's own devcontainer — whose
initializeCommandis the relative path.devcontainer/claude-code/init-host.sh— bothdevpod up . --recreateandstop+upsucceeded on devpod v0.26.1 with a local-folder source, including from a neutral cwd. devpod appears tocdto the workspace folder before running the hook.So this bug is narrower than "relative
initializeCommandbreaks recreate" — that combination works on v0.26.1. Whatever triggers it is something else: a different devpod version, a git/image source rather than a local folder, or a different cwd discipline. Offered as evidence, not a fix — I have not tried to reproduce your failing case.blooop commentedon Aug 13, 2026
Closing as superseded by #88, which now holds all the work.
The root cause was found and re-scoped entirely onto #88:
devpod_workspace_idis declared (worktree/models.py:71) and never written by production code, so every devpod-addressing path re-derives the id instead of reading the one devpod actually knows.recreate/restartfailing on a relativeinitializeCommandis a symptom of that, not a separate defect.This ticket has held no work of its own since that re-scoping — keeping both open means two tickets tracking one fix, and #88 is the one carrying the "Done when" criteria.
The reported symptom is still live; it is not fixed by closing this. Anyone hitting
recreate/restartfailures should follow #88.