Codespace rebuild after a failed upgrade: which changes survive and which are lost
0 reputation · 08 Jan 2021, 08:39 UTC
Scenario
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.
Uncertainty
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.
Questions
- Which locations does a rebuild treat as persistent, and is the home directory or dotfiles content covered by the persistent volume or lost with the container?
- If the referenced image tag no longer exists, does the rebuild fail cleanly with a recoverable error, or silently fall back to a different image?
- Before triggering the rebuild, what is the recommended way to confirm which uncommitted changes would be discarded?