Codespace rebuild after a failed upgrade: which changes survive and which are lost
0 reputation · 08 Jan 2021, 08:39 UTC
0 reputation · 08 Jan 2021, 08:39 UTC
A GitHub Codespace running a dev container definition needs to be recovered after an in-container upgrade left the environment in a broken state. A rebuild from the Codespace details page (or the CLI rebuild command) is the documented recovery path, since it re-provisions the VM and reinstates the dev container configuration.
The rebuild discards runtime modifications made since creation, while persistent volumes are preserved across rebuilds. The unclear boundary is exactly which data falls on each side: files and packages written outside the volume mount point appear to be lost, but it is not obvious how this interacts with the home directory, dotfiles, and anything installed by postCreateCommand versus installed manually afterwards. There is also a risk that the dev container definition references an image tag that has since been removed or renamed, which could make the rebuild fail or fall back to a base image.
33275 reputation · 08 Jan 2021, 09:21 UTC
A GitHub Codespace rebuild effectively destroys the current container and provisions a new one based on your devcontainer.json. The following rules determine what survives:
/workspaces/ directory. Any files, uncommitted git changes, or data stored within your repository folder survive the rebuild because they reside on a persistent volume mount.apt-get or yum, modifications to /etc, and any binaries installed to /usr/local/bin manually after the initial setup./home/vscode). By default, changes here are lost. However, if you have a Dotfiles repository linked to your GitHub account, those configurations are reapplied during the rebuild process.When you trigger a rebuild, Codespaces attempts to pull the image specified in your configuration. If the referenced image tag no longer exists in the registry, the rebuild will fail with an image pull error. It does not silently fall back to a different image; the process will stop, and you will be notified that the container could not be started.
To identify what will be lost before you trigger the rebuild, you must distinguish between workspace data and system state. Use these scoped commands to audit your environment:
# Check for files outside the workspace volume
find /home/vscode -maxdepth 1 -not -path '/home/vscode' -not -path '/home/vscode/.'
# List manually installed packages (requires knowing the baseline)
dpkg -l | grep -v "installed"
Any configuration or tool not explicitly defined in your devcontainer.json (via features or postCreateCommand) or your Dotfiles repository will be discarded.
/home/vscode or /tmp into the /workspaces/ folder.devcontainer.json uses a stable image tag to avoid pull failures.Codespaces: Full Rebuild Container).Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.