`devcontainer up --mount` rejects `type=image` and mount options such as `subpath`

Ouverte
  • Quelque chose ne va pas ?
#1,352 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@agmitron y travaille déjà.

Depuis le 6/11/2026.

  • #1353 par @agmitron — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
docker, docker-compose, typescript
Domaine
cli, devtools

Piste de recherche

Trace how the --mount flag is validated and converted, then compare it with how string mounts from devcontainer.json reach the runtime. Check the Docker Compose path, where mounts use short syntax, and define a clear rejection for unsupported mount forms there. Done means runtime string mounts are passed through for supported runtimes, existing bind/volume behavior remains covered, and the linked pull request is reviewed for overlap.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

What I want to do

I keep my personal tools (neovim, Claude Code) in a Nix-built OCI image and mount its /nix read-only into a team's dev container with an image mount. The team's devcontainer.json stays untouched, so the mount has to come from the command line:

devcontainer up --docker-path podman --workspace-folder . \
  --mount "type=image,source=localhost/devtools:latest,target=/nix,subpath=/nix"

Podman (since 5.1) and Docker Engine (since 28, with the containerd image store) support --mount type=image. Docker spells the option image-subpath instead of subpath.

What happens

The CLI exits with:

Unmatched argument format: mount must match type=<bind|volume>,source=<source>,target=<target>[,external=<true|false>]

The same string works as an entry in mounts in devcontainer.json. The CLI passes string mounts to podman run verbatim, and with --log-level trace I see:

podman run ... --mount type=image,source=localhost/devtools:latest,target=/nix,subpath=/nix ...

Inside the container, /nix is a read-only overlay, and nvim --version and claude --version run from it. So the runtime handles the mount fine; only the --mount flag refuses it.

Why

In 0.89.0 the flag goes through two steps:

  1. A fixed regex validates it: /^type=(bind|volume),source=([^,]+),target=([^,]+)(?:,external=(true|false))?$/. Any other type or option fails, including readonly.
  2. The value is parsed into a mount object, and the object is serialized back as type=...,src=...,dst=.... Options outside these three fields would be lost even if the regex allowed them.

The object form follows the spec's Mount schema (type is bind or volume, additionalProperties: false).

Proposal

When the --mount value does not match the bind/volume form, pass it to the container runtime as a string, the same way string entries in devcontainer.json mounts are handled today. The bind/volume parsing and external= keep working as now.

That covers type=image, subpath / image-subpath, readonly, volume-subpath, tmpfs and future runtime options without the CLI having to know each one. The runtime reports an invalid string itself.

For Docker Compose configs the string cannot be passed through as-is, since mounts are converted to the short source:target syntax there. Rejecting a non-bind/volume --mount with a clear error on the Compose path would be enough.

Workaround

--override-config with a full copy of the team's devcontainer.json plus the string mount. The copy has to be regenerated whenever the team changes their file, because --override-config replaces the config instead of merging it.

Environment
  • @devcontainers/cli 0.89.0
  • Podman 6.1.4, rootless, Debian 13 (Linux 6.12, x86_64)
Related
  • devcontainers/spec#781: the Feature Mount schema rejects --mount options such as volume-subpath
  • devcontainers/spec#511: no way to declare a read-only mount in object form
  • devcontainers/cli#881 and devcontainers/cli#1314: readonly is dropped when mounts are converted
Langage dominant
TypeScript
Étoiles
3k
Forks
473
Merge moyen
10 h 31 min
PR mergées (30 j)
9

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de devcontainers/cli

Toutes les issues de devcontainers/cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.