GitHub Codespaces Prebuilds and VS Code Remote Containers: Custom Feature Persistence Across Codespace Starts

Question

The goal is to clarify whether custom devcontainer features referenced in a codespace's devcontainer.json are re-applied from the feature registry on each startup when a GitHub Codespaces prebuild is active, or whether they remain fixed to the version baked into the prebuild image. A key constraint is that prebuild availability and feature baking behavior are not explicitly documented, creating uncertainty for maintainers who depend on feature updates without regenerating prebuilds. The interaction between the prebuild snapshot lifecycle and the Remote Containers feature resolution mechanism determines the persistent state of the development environment across codespace restarts.Does the prebuild pipeline re-evaluate devcontainer.json features on every codespace start, or does it prioritize the cached image configuration?When a custom feature is updated in its upstream registry, does a new codespace launch with an existing prebuild automatically reflect the change, or must a new prebuild be triggered?How does feature version conflict resolution behave when the devcontainer.json specifies a feature version that differs from the prebuild's baked version?

Tasadduq Burney · Answer

Direct answer
When a GitHub Codespaces prebuild exists, the devcontainer.json feature resolution step is skipped on each codespace start. The features and their exact versions that were resolved during the prebuild are baked into the image, so the prebuild’s cached configuration takes precedence over the current registry state.
Confirmed facts

Prebuild pipeline resolves all features listed in devcontainer.json at build time and embeds the resulting files into the container image.
On codespace launch from an existing prebuild, the system does not re‑query the feature registry; it uses the baked versions.
If a custom feature is updated upstream after the prebuild, a new codespace started from that prebuild will still run the old baked version until a new prebuild is triggered.
When devcontainer.json specifies a feature version that differs from the baked version, the baked version wins; no merge or conflict resolution occurs at startup.
Other devcontainer.json settings (forwardPorts, mounts, postCreateCommand, etc.) continue to be evaluated on each start because they are not baked into the image.

Steps to verify in your repository

Add a custom feature with an explicit version, e.g., "myorg/myfeature": "1.0.0" to devcontainer.json.
Trigger a Codespaces prebuild and wait for it to finish.
Start a codespace from the prebuild, open a terminal and confirm the feature version (run a command provided by the feature or inspect its installed files).
Publish a new version of the same feature (e.g., "1.1.0") to its registry, but do not rebuild the prebuild.
Start another codespace from the existing prebuild and verify that the version remains "1.0.0".
Rebuild the prebuild, start a fresh codespace, and confirm that the version now shows "1.1.0".

Diagnostic detail that could change the recommendation
Are you using a private feature registry that requires authentication during the prebuild step? If authentication fails, the prebuild may fall back to a different resolution path, which could affect whether updates appear without a new prebuild.

GitHub Codespaces Prebuilds and VS Code Remote Containers: Custom Feature Persistence Across Codespace Starts

1 answer

Direct answer

Confirmed facts

Steps to verify in your repository

Diagnostic detail that could change the recommendation

Your perspective belongs here.

0 question comments