Wasmtime GitHub notifications bot (Jul 30 2026 at 16:53): Wasmtime GitHub notifications bot (Jul 30 2026 at 16:53):fitzgen closed issue #593:
Commit d9edb9521870e086bd7919691beabe719a7dd5d0 made wasmtime-interface-types automatically look for wasm binaries that import WASI, and enable WASI for them (with a default configuration).
For security reasons, a user/embedder of wasmtime may not necessarily want to let a wasm binary use WASI, and especially may not want to allow it if unconfigured. An embedder may instead want to use wasm for pure compute and not give it the full WASI interface, or hand it only a few special-purpose functions, for instance. Or, a user/embedder may have different policies for WASI binaries and more heavily sandboxed wasm binaries with minimal API surface areas.
I'm filing this issue to discuss general policy with respect to enabling WASI. How can we make it relatively convenient to use WASI, while also making it convenient to use wasm without WASI, and not accidentally doing the former when someone expected the latter?
Wasmtime GitHub notifications bot (Jul 30 2026 at 16:53):fitzgen commented on issue #593:
I don't think this is applicable anymore today. Wasmtime's embedding API and CLI both have knobs for explicitly enabling/disabling WASI.
Last updated: Aug 30 2026 at 09:07 UTC