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

Aberta
  • Algo errado?
#1,352 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@agmitron já está trabalhando nisso.

Desde 6/11/2026.

  • #1353 de @agmitron — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
docker, docker-compose, typescript
Domínio
cli, devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
TypeScript
Estrelas
3k
Forks
473
Merge médio
10h 31min
PRs com merge (30d)
9

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de devcontainers/cli

Todas as issues de devcontainers/cli

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.