Stream: git-wasmtime

Topic: wasmtime / issue #13873 CLI --dir cannot represent direct...

Wasmtime GitHub notifications bot (Jul 13 2026 at 20:37):

MacroModel opened issue #13873:

The existing --dir=HOST::GUEST syntax is ambiguous when either path contains ::.

Consider supporting a two-argument form:

wasmtime --dir HOST GUEST program.wasm

The existing syntax could remain as a backward-compatible alias:

--dir=HOST::GUEST

This avoids introducing custom escaping rules and lets both paths represent valid filesystem names directly.

Wasmtime GitHub notifications bot (Jul 13 2026 at 20:42):

MacroModel edited issue #13873:

The existing --dir=HOST::GUEST syntax is ambiguous when either path contains ::.

Consider supporting a two-argument form:

wasmtime --dir HOST GUEST program.wasm

The existing syntax could remain as a backward-compatible alias:

--dir=HOST::GUEST

This avoids introducing custom escaping rules and lets both paths represent valid filesystem names directly.

the ("--dir HOST GUEST" and "--dir=HOST::GUEST") two-argument behavior may be unclear.Consider:

wasmtime --map-dir A::B C::D program.wasm

The existing --dir syntax can remain supported for backward compatibility (only in the --dir=HOST::GUEST form). Meanwhile, --map-dir more clearly conveys that the first directory is mapped to the second, while avoiding the need for any custom escaping rules.

Wasmtime GitHub notifications bot (Jul 14 2026 at 13:53):

tschneidereit commented on issue #13873:

Is this a problem you're hitting in practice and in ways you can't work around? I'm asking because introducing new CLI syntax isn't exactly cheap: it requires us to carefully reason through how existing uses might be broken by it or what side-effects otherwise might be, for example. And I'm pretty sure that your proposed syntax isn't something we'd want to do: it introduces ambiguity around whether something is a positional argument or an option, for example.

Wasmtime GitHub notifications bot (Jul 14 2026 at 16:23):

MacroModel commented on issue #13873:

Is this a problem you're hitting in practice and in ways you can't work around? I'm asking because introducing new CLI syntax isn't exactly cheap: it requires us to carefully reason through how existing uses might be broken by it or what side-effects otherwise might be, for example. And I'm pretty sure that your proposed syntax isn't something we'd want to do: it introduces ambiguity around whether something is a positional argument or an option, for example.

Thanks for the clarification. I’m raising this primarily as a representational edge case, not suggesting that directories containing :: are common.

The core issue is that :: can be valid path data on Unix-like systems while also serving as the delimiter in the CLI syntax. With the current parser, for example, A::B::C is interpreted as host A and guest B, so the remaining component cannot be represented. It is therefore not possible to reliably express a literal :: in either path.

One practical case could be a path exposed by a filesystem driver, mount, or external system that the user cannot rename. For a host path, the user may be able to work around this by creating a symlink or another alias whose path does not contain ::, assuming they have permission to do so. That is a viable workaround, but it is still an extra filesystem-level workaround for a CLI encoding limitation.

I agree that --dir HOST GUEST may introduce ambiguity with positional arguments, so I’m not attached to that exact syntax. My main goal is to make the limitation explicit. A separate unambiguous form such as --map-dir, or even documentation of the limitation and the host-side symlink workaround, would address the concern.

Wasmtime GitHub notifications bot (Jul 14 2026 at 16:25):

MacroModel edited a comment on issue #13873:

Is this a problem you're hitting in practice and in ways you can't work around? I'm asking because introducing new CLI syntax isn't exactly cheap: it requires us to carefully reason through how existing uses might be broken by it or what side-effects otherwise might be, for example. And I'm pretty sure that your proposed syntax isn't something we'd want to do: it introduces ambiguity around whether something is a positional argument or an option, for example.

Thanks for the clarification. I’m raising this primarily as a representational edge case, not suggesting that directories containing :: are common.

The core issue is that :: can be valid path data on Unix-like systems while also serving as the delimiter in the CLI syntax. With the current parser, for example, A::B::C is interpreted as host A and guest B, so the remaining component cannot be represented. It is therefore not possible to reliably express a literal :: in either path.

One practical case could be a path exposed by a filesystem driver, mount, or external system that the user cannot rename. For a host path, the user may be able to work around this by creating a symlink or another alias whose path does not contain ::, assuming they have permission to do so. That is a viable workaround, but it is still an extra filesystem-level workaround for a CLI encoding limitation.

I agree that --dir HOST GUEST may introduce ambiguity with positional arguments, so I’m not attached to that exact syntax. My main goal is to make the limitation explicit.

Wasmtime GitHub notifications bot (Jul 14 2026 at 16:31):

MacroModel edited a comment on issue #13873:

Is this a problem you're hitting in practice and in ways you can't work around? I'm asking because introducing new CLI syntax isn't exactly cheap: it requires us to carefully reason through how existing uses might be broken by it or what side-effects otherwise might be, for example. And I'm pretty sure that your proposed syntax isn't something we'd want to do: it introduces ambiguity around whether something is a positional argument or an option, for example.

Thanks for the clarification. I’m raising this primarily as a representational edge case, not suggesting that paths containing :: are common.

There is an important asymmetry between the host and guest sides.

On the host side, if the actual filesystem path contains :: and the user has permission to create a symlink or another alias, the issue can usually be worked around. For example, an alias without :: can point to the real system path containing ::, and that alias can then be passed to Wasmtime. The underlying host directory is still accessible; only the CLI-facing path needs to avoid the delimiter.

The guest-side preopen path does not have an equivalent workaround. The current parser splits on every occurrence of ::, takes only the first component as the host path and the second as the guest path, and silently discards the remaining components.

For example:

--dir=A::B::C

is parsed as host A and guest B; the trailing ::C is discarded. Therefore, the current CLI cannot assign a preopened directory the exact WASI guest path B::C.

Mapping a parent directory may allow a program to access a child whose name contains ::, but that only works when the program does not require the preopen itself to have that exact name. If a Wasm program specifically expects a preopened directory named B::C, there is currently no way to express that mapping through --dir.

I agree that --dir HOST GUEST may introduce ambiguity with positional arguments, so I’m not attached to that particular syntax. My main concern is that the current syntax cannot represent every otherwise-valid guest preopen path.

Wasmtime GitHub notifications bot (Jul 14 2026 at 17:00):

tschneidereit commented on issue #13873:

I'm not sure about others, but I'm inclined to just leave this as-is. As you point out, there are host-side workarounds, and I think the scenario you describe where the guest absolutely must use :: is too far-fetched for us to spend time on. "the current syntax cannot represent every otherwise-valid guest preopen path" might be sufficient motivation with infinite amounts of time, but as-is, I doubt we'd ever run out of higher-priority work to take on first.

Last updated: Jul 29 2026 at 05:03 UTC