Lifecycle marker files in home directory break persistent home volume across rebuilds

Problem

Devcontainer lifecycle marker files (.onCreateCommandMarker, .postCreateCommandMarker, .updateContentCommandMarker, .dotfilesMarker) are stored in ~/.devcontainer/. When the home directory is backed by a named volume to persist user data across rebuilds, these markers survive and cause all lifecycle commands and dotfiles installation to be silently skipped.

Motivation

Experimenting with devcontainer configuration requires frequent rebuilds. A typical home directory accumulates cached data and state that is both valuable and costly to recreate:

• Tool caches (e.g. clangd index, pip/npm caches) — some of which take significant time to rebuild or re-download
• Shell history, dotfiles state
• Editor/tool configuration generated at runtime

The workaround of creating separate named volumes for each specific subdirectory is impractical. These files are spread across many locations in the home tree (~/.cache/, ~/.local/, ~/.config/, tool-specific dotfiles, etc.), and tracking exactly which tool creates files where is an implementation detail users shouldn't need to learn. It also doesn't scale — any new tool that caches data under $HOME would require adding yet another volume.

Since a home volume is scoped per-devcontainer, there is no risk of version mismatches between container images and cached/configuration files in the home directory.

Issue #421 led to improvements for ~/.vscode-server (extension install markers), but the broader problem remains: the ~/.devcontainer/ lifecycle markers still reside in the user's home directory and break the named-volume-for-home workflow.

Proposed solution

1. Move lifecycle markers out of $HOME: Store them in a container-scoped path (e.g. /var/lib/devcontainer/markers/) that is not affected by user-mounted volumes. The home directory is the user's domain; the devcontainer runtime should not depend on files placed there.

2. Add a setting for persistent home volumes (e.g. dev.containers.homeVolume: true or a "homeVolume" property in devcontainer.json): Automatically create and mount a per-devcontainer named volume for the home directory. This should have been the default behavior from the beginning — destroying the home directory on every rebuild wastes bandwidth and time recreating hundreds of megabytes of data that will inevitably be regenerated.

Related

• #1153 — postCreateCommand skipped with named volume for ~/.vscode-server
• #421 — Extension volume support (partially addressed)