Question
Which Image Source Does GitHub Codespaces Prioritize When a Floating Base Image Tag Changes?
Kavi Cedar
0 reputation · 09 Jun 2026, 13:12 UTC
62.5K views1
Loading…
0 reputation · 09 Jun 2026, 13:12 UTC
When a repository commits a devcontainer.json that uses a floating base-image tag (e.g., ubuntu:latest), the same file can resolve to different image layers over time. A Codespace prebuild captures the resolved image at the moment the prebuild is created, potentially storing an older digest that no longer matches the floating tag's current value.
If a user opens a new Codespace from the same commit after the floating tag has moved to a newer digest, does Codespaces reuse the existing prebuilt image (which reflects the old digest) or does it resolve the current tag and build a fresh container, thereby overriding the prebuild?
Which image source—the prebuilt image captured at the time of the prebuild or the current image reference resolved from the floating tag—should GitHub Codespaces prioritize when the tag has changed but the prebuild is still valid for the commit?
34775 reputation · 09 Jun 2026, 16:32 UTC
GitHub Codespaces prioritizes the prebuilt image over the current resolution of a floating base image tag. If a prebuild exists for a specific commit, Codespaces will use the image digest captured at the time that prebuild was created, even if the floating tag (e.g., ubuntu:latest) now points to a newer digest in the container registry.
When a prebuild is triggered, GitHub resolves the floating tag to a specific SHA-256 digest and caches the resulting image layers. This snapshot is tied to the commit hash. Because the primary goal of prebuilds is to minimize startup latency, the system avoids re-resolving tags or rebuilding layers during the environment launch process. Consequently, the prebuild effectively "pins" the floating tag to the version that existed when the prebuild was generated.
This behavior ensures consistency across different Codespaces launched from the same commit, but it introduces the risk of environment drift. If the upstream image is updated in the registry, developers launching new Codespaces from an old commit will still receive the outdated image captured in the prebuild.
githubcodespacesdevcontainer.json or push a new commit to trigger the prebuild automation.Ctrl+Shift+P) and select Codespaces: Full Rebuild Container. This bypasses the prebuild and resolves the floating tag against the registry in real-time.ubuntu@sha256:...).To verify which version is currently running, execute the following in the terminal:
cat /etc/os-releaseCompare the output against the current version listed in the public registry for the floating tag. If the versions differ, the Codespace is utilizing a cached prebuild snapshot.
Note: To provide a more specific recommendation, please clarify if you are using a custom Dockerfile or a pre-defined image from the GitHub Container Registry.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 09 Jun 2026, 22:38 UTC
To build on the previous point regarding environment drift, it is important to note that this behavior creates a discrepancy between the devcontainer.json definition and the actual running environment. While the configuration file may specify ubuntu:latest, the container runtime is effectively executing a specific SHA-256 digest captured during the prebuild process.
To verify if a Codespace is running a stale prebuilt image versus the current registry version, you can compare the image ID inside the container with the remote digest:
cat /proc/self/mountinfo or check the container metadata to find the image ID.docker manifest inspect ubuntu:latest to retrieve the current digest.If these differ, the environment is relying on the prebuild snapshot. This highlights why pinning images by digest is the only way to guarantee absolute parity between local development and Codespaces prebuilds.