Mount selection is a data-boundary decision. Start with who owns the files, whether a person or tool needs a particular host directory, how long the data must remain available, whether another container needs it, and whether development runs locally or remotely. The containers.dev excerpts are shared specification and metadata material; the retention, migration, and approval rules below are proposed application policy.
Choose the boundary before the syntax
The supplied Dev Container specification material presents mounts as a means to reach machine data, exchange information between containers, and retain information through development-container replacement. It also describes keeping workspace source outside the container so work can be recovered or used when creating another container.
Docker's volume guidance characterizes a volume as Docker-administered persistent storage, separate from an individual container's lifetime. That guidance positions bind mounts for cases where host and container both need file access. Therefore, a requirement for a chosen host path is a reason to consider a bind mount; persistence without that host-path requirement is a reason to consider a Docker-managed volume.
Sharing is a separate question. The Docker excerpt permits more than one container to mount a volume and describes read-only mounting. That capability does not define an application's access-control, backup, cleanup, or ownership rules.
Four concrete decisions
| Case | Data owner | Host-access requirement | Persistence requirement | Supported mount choice | Configuration boundary | Inference to reject | Bounded application-owned action |
|---|---|---|---|---|---|---|---|
| Repository source edited on the host | Project team | Yes: edits originate in the host workspace. | Yes: source must outlive a replaceable development container. | Workspace bind mount. | Use the workspace-mount and workspace-folder metadata boundary; the specification advises a repository-root source mount for in-container source control. | “Container writable-layer files are an adequate replacement for the host working tree.” | Record the repository owner and keep the workspace boundary explicit. |
| An additional host folder needed inside the container | Host user or team that owns that folder | Yes: a particular host directory is required. | Determine this separately from the container lifecycle. | Additional bind mount. | For image or Dockerfile setups, place the additional mount in devcontainer.json; for Compose setups, place it on the relevant service's volumes configuration. | “A Docker-managed volume provides access to my selected host directory.” | Approve the host path and its permission expectations before adding the mount. |
| Persistent generated data that needs no host-path access | Application team | No selected host directory is required. | Yes: data must survive replacement of one container. | Docker-managed volume. | Use a volume-form mount through the selected container configuration boundary. | “Persistent container data must be placed in a host-visible directory.” | Set a volume name, retention period, cleanup owner, and migration approval rule. |
| A GitHub Codespaces environment proposed to use a local bind mount | Remote-environment owner, to be designated | A local host path cannot be assumed. | Define remote retention separately. | Do not select a local bind mount for this case. | The supplied VS Code guidance marks local-file-system mounting unsupported in GitHub Codespaces and points readers to remote Docker-host development information for remote-folder scenarios. | “Every Dev Container has the same local filesystem boundary.” | Choose and document a remote storage or artifact-transfer boundary before implementation. |
The table is deliberately conditional rather than universal. A bind mount can answer a host-path requirement, while a volume can answer a container-managed persistence requirement; the application still owns the decision about naming, access approval, retention, and migration.
Configuration boundaries and compatibility
The metadata reference describes mounts as an additional-mount field whose values follow Docker --mount-style values, and it allows environment or predefined variables in those values. It also states that workspaceMount works together with workspaceFolder when overriding the normal workspace mount.
The supplied VS Code local-mount guidance identifies the mounts property for image or Dockerfile configurations as applicable from VS Code 1.41 onward. It directs Docker Compose users to the service-level volume declaration instead. If a local mount changes after a container is already connected, that guidance calls for rebuilding the container to apply the change.
Verify the intended tool, orchestration mode, and compatibility before adopting either boundary. This article is limited to the supplied excerpts and does not claim a release-status classification beyond the stated VS Code applicability.
Hypothetical failure walkthrough
Consider an explicitly hypothetical team whose generated artifacts later require host review. It initially classifies the artifacts as container-owned and places them in a Docker volume. That is a mismatch: the volume may persist independently of the individual container, but it does not satisfy a newly discovered requirement for a chosen host directory.
- Preserve the volume rather than treating container replacement as automatic artifact loss.
- Correct the requirement classification: host review means that an approved host-path boundary is now required.
- Have the designated data owner approve a migration plan to a bind mount, including permissions, transfer steps, retention, rollback, and cleanup.
- Perform the migration only after the team has selected the applicable Dev Container configuration boundary and checked its tooling compatibility.
This is a proposed response pattern, not a claim that the migration has been executed or that a volume alone meets a host-review requirement.
Policy limits and remote alternatives
Adopt an application policy that records the data owner, requested host visibility, retention class, sharing need, and approval authority for every non-workspace mount. Require an owner-approved change when data moves between a Docker-managed volume and a host bind mount.
For remote development, treat the storage or artifact-transfer boundary as a separate architecture decision. In particular, do not carry a local-path assumption into GitHub Codespaces, because the supplied local-mount guidance says that local filesystem mounting is unsupported there. A remote alternative must specify ownership, retention, access review, and retrieval separately.
Open questions remain: which team approves host-path exposure, what retention and backup rules apply to generated data, how anonymous-volume cleanup is handled, and which remote boundary replaces local review. The supplied material describes mount mechanisms and constraints, not answers to those application-policy questions.
Does “authoritative” here mean both recovery authority and the repository-visible topology? A workspace bind mount is the right primary boundary when host edits must remain recoverable, but repository-aware work additionally depends on the mounted tree containing the repository root and
.git. The specification permitsworkspaceFolderto be a descendant for monorepos; it is therefore an entry path, not an alternative source boundary. Make the dependency explicit:host working tree --bind mount--> container repository root (.git) └--> workspaceFolder (optional subproject)That distinction prevents a configuration from appearing correct merely because a tool opens a package directory. The specification says source is kept outside the container so in-flight edits can be recovered or used by a replacement container, and says the workspace mount should point at the repository root for in-container source control. It also requires
workspaceMountandworkspaceFoldertogether when the default workspace mount is overridden. Should the proposed policy require a topology check that the selectedworkspaceFolderis under the primary mounted repository tree, plus an access check for the effective user, before calling the bind mount authoritative? Dev Container Specification Dev Container JSON reference