recreate/restart fail on a relative initializeCommand

[blooop]

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.sh has existed since the initial commit (195bb3d) and is mode 100755 on main. initializeCommand was 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. recreate is dispatched at dl.py:1219 before 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.

[blooop]

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.json intact, 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]

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]

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>, migrated dl's metadata.json, and left devpod's own workspace records pointing at the old paths.

For devlaunch-main on this host:

• metadata.json → …/devlaunch/devlaunch-main-zovomobo — real checkout, init-host.sh present
• devpod's workspace.json → …/devlaunch/main — 1 file, no .git

The 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.sh is repo content, not devcontainer config, so it was never restored. Hence not 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 initializeCommand reference 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, so dl'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 at worktree/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]

Narrowing datum from a neighbouring map (#93's prototype ticket, #94).

While building this repo's own devcontainer — whose initializeCommand is the relative path .devcontainer/claude-code/init-host.sh — both devpod up . --recreate and stop + up succeeded on devpod v0.26.1 with a local-folder source, including from a neutral cwd. devpod appears to cd to the workspace folder before running the hook.

So this bug is narrower than "relative initializeCommand breaks 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]

Closing as superseded by #88, which now holds all the work.

The root cause was found and re-scoped entirely onto #88: devpod_workspace_id is 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/restart failing on a relative initializeCommand is 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/restart failures should follow #88.