Skip to content

Set stable WORKDIR so dotfiles install survives docroot swap (#45)#51

Merged
kurowski merged 2 commits into
mainfrom
fix/45-shellserver-workdir
Jun 9, 2026
Merged

Set stable WORKDIR so dotfiles install survives docroot swap (#45)#51
kurowski merged 2 commits into
mainfrom
fix/45-shellserver-workdir

Conversation

@kurowski

@kurowski kurowski commented Jun 9, 2026

Copy link
Copy Markdown
Member

Problem

Dotfiles install still fails on the first devcontainer up with:

Start: Run in container: # Clone & install dotfiles
Cloning into '/home/vscode/.../dotfiles'...
fatal: Unable to read current working directory: No such file or directory
fatal: remote helper 'https' aborted session

Reopened #45 with the full analysis. The _cwd_workspace / cd "$WORKSPACE_FOLDER" fix in #48 doesn't work, because lifecycle commands and the dotfiles clone run in different processes.

Root cause

  • The devcontainer CLI runs the dotfiles clone in its persistent shellServer, which it starts with no -w — so the shell inherits the image's WORKDIR, /var/www/html (from the php base image; we never override it).
  • devcontainer_on_create.sh:20 does sudo rm -rf /var/www/html && sudo ln -s "$(pwd)/web" /var/www/html. That rm -rf unlinks the directory the shellServer is sitting in, orphaning its cwd.
  • The later git clone runs in that same shellServer; git-remote-https calls getcwd(), gets ENOENT, and aborts.
  • Lifecycle commands run as separate docker exec -w /workspaces/<repo> processes, so the cd "$WORKSPACE_FOLDER" at the end of those scripts (from Fix dotfiles install (#45) and upgrade to PHP 8.4 #48) changes a process that immediately exits and never touches the shellServer.

Fix

Set a stable WORKDIR in the Dockerfile so the shellServer starts — and stays — in a directory the lifecycle scripts never delete:

WORKDIR /home/vscode

The docroot symlink swap on on-create:20 is unchanged. The _cwd_workspace additions from #48 are left in place as harmless lifecycle-script hygiene.

Verification

Minimal reproduction of the mechanism (reproduces the exact error), and confirmation that anchoring the shell's cwd away from the deleted directory resolves it, is in #45. Building the image with this change and running dce with --dotfiles-repository set completes the clone successfully.

Closes #45

🤖 Generated with Claude Code

kurowski and others added 2 commits June 9, 2026 09:29
The php base image leaves WORKDIR at /var/www/html, which
devcontainer_on_create.sh deletes and replaces with a symlink to the
mounted docroot. The devcontainer CLI starts its persistent setup shell
("shellServer") in WORKDIR with no -w flag, so that rm -rf orphans the
shell's cwd. The later dotfiles `git clone` runs in the same shellServer
and fails its getcwd() with "Unable to read current working directory".

The lifecycle commands run as separate execs (-w workspaceFolder), so
the cd "$WORKSPACE_FOLDER" added in #48 can't repair the shellServer.
Anchoring WORKDIR to /home/vscode keeps the shellServer's cwd valid
through the docroot swap.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The cd "$WORKSPACE_FOLDER" appended to devcontainer_on_create and
devcontainer_post_create in #48 was meant to leave the devcontainer
CLI's persistent shellServer in a valid cwd before the dotfiles clone.
It can't: each lifecycle command runs in its own `/bin/sh -c` exec that
exits as soon as the function returns, so the cd never touches the
shellServer. The real fix is anchoring the image WORKDIR (prior commit).

Kept _cwd_workspace at the top of each script — on_create's docroot
symlink (ln -s "$(pwd)/web" ...) depends on a deterministic cwd, so that
call is load-bearing, not part of the broken cwd-restore theory.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@kurowski kurowski merged commit c3b6f96 into main Jun 9, 2026
1 check passed
@kurowski kurowski deleted the fix/45-shellserver-workdir branch June 9, 2026 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dotfiles install fails with "Unable to read current working directory" after lifecycle scripts run

1 participant