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

[kurowski]

When using --dotfiles-repository with a devcontainer based on ghcr.io/uceap/devcontainer-drupal:main, the dotfiles git clone step fails on the very first devcontainer up:

[93816 ms] Start: Run in container: # Clone & install dotfiles
[93819 ms] Cloning into '/home/vscode/dotfiles'...
[93829 ms] fatal: Unable to read current working directory: No such file or directory
[93829 ms] fatal: remote helper 'https' aborted session
[93830 ms] Exit code 128

The error has nothing to do with the dotfiles repo — it's git-remote-https failing getcwd() because the shellServer's cwd is no longer accessible.

Why this matters beyond dotfiles: the devcontainer CLI sets the dotfiles install marker before attempting the clone. After this failure, every subsequent devcontainer up reports dotfiles marker found and silently skips the install — so the user is stuck with a broken setup with no error in normal output.

Suspected cause: the devcontainer CLI's dotfiles install reuses the same shellServer that ran onCreateCommand / updateContentCommand / postCreateCommand. Looking at local/etc/uceap.d/:

• devcontainer_update_content.sh calls _cwd_workspace ✓
• devcontainer_on_create.sh does not call _cwd_workspace ✗
• devcontainer_post_create.sh does not call _cwd_workspace ✗

Something during onCreate (likely the composer dev-initialize-local / composer install chain, or the apache/symlink reshuffle) appears to invalidate the workspace folder inode that the shellServer cd'd into. The shellServer's cwd reference goes stale, but no command in the lifecycle script needs cwd, so the failure is invisible until git's helper subprocess tries to start.

Proposed fix: add _cwd_workspace to the top of devcontainer_on_create and devcontainer_post_create, and have each function explicitly cd "$WORKSPACE_FOLDER" as its final step so the shellServer is left in a known-good state for any subsequent step (including the CLI's own dotfiles install).

Repro:

1. dck && dce against a myeap2 / portal / web devcontainer with --dotfiles-repository set
2. Observe Exit code 128 in the dotfiles step
3. docker exec -u vscode <container> ls ~/dotfiles → directory is empty/missing
4. docker exec -u vscode <container> ls ~/.devcontainer/.dotfilesMarker → marker file is present

Workaround: in the container, rm ~/.devcontainer/.dotfilesMarker, then manually git clone <repo> ~/dotfiles && bash ~/dotfiles/setup.sh from cd ~.