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

Aperta
  • Qualcosa non va?
#1,352 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@agmitron ci sta già lavorando.

Dal 6/11/2026.

  • #1353 di @agmitron — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
docker, docker-compose, typescript
Ambito
cli, devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
TypeScript
Stelle
3k
Fork
473
Merge medio
10h 31m
PR unite (30g)
9

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di devcontainers/cli

Tutte le issue di devcontainers/cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.