Feature-gated Wasm host tools for the CLI#91
Conversation
Signed-off-by: akrm al-hakimi <alhakimiakrmj@gmail.com>
Signed-off-by: akrm al-hakimi <alhakimiakrmj@gmail.com>
Signed-off-by: akrm al-hakimi <alhakimiakrmj@gmail.com>
Signed-off-by: akrm al-hakimi <alhakimiakrmj@gmail.com>
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds support for registering and invoking host-side custom tools implemented as WASI Preview1 WebAssembly modules (behind an optional Cargo feature), including CLI flags and documentation updates.
Changes:
- Introduces a
wasm-host-fnsfeature with optionalwasmtime/wasmtime-wasidependencies and a new Wasm tool runner (WasmTool). - Extends the host CLI to register
--tool NAME=WASMtools and configure their WASI capabilities/limits (--tool-wasi-*). - Updates docs and README to describe the new tool mechanism and its security/limits model.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| host/src/wasm_host_fns.rs | New Wasm tool loader/invoker with WASI Preview1 wiring, option parsing, stdout parsing, and tests. |
| host/src/main.rs | Adds feature-gated CLI flags for Wasm tools and registers tools into SandboxBuilder. |
| host/Cargo.toml | Adds wasm-host-fns feature and optional wasmtime / wasmtime-wasi deps. |
| docs/host_functions.md | Documents --tool and --tool-wasi-* behavior, protocol, and limits. |
| README.md | Updates dispatch surface description and adds usage docs for Wasm host tools. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Signed-off-by: akrm al-hakimi <alhakimiakrmj@gmail.com>
danbugs
left a comment
danbugs
left a comment
There was a problem hiding this comment.
This is AWESOME!! Thank you so much for the contribution! Just ggot some comments here and there for you to consider.
| | `--net-block HOST_OR_IP` | Block-list; all other destinations allowed (implies `--net`). Mutually exclusive with `--net-allow`. | | ||
| | `--port PORT` | Allow `net_bind` / listen on `PORT` (implies `--net`). Without `--port`, outbound-only: bind is rejected. | | ||
| | `--enable-tools` | Enables custom tool registration. Registers a built-in `echo` tool (used by the `python-tools` example). Library users add their own tools via `SandboxBuilder::tool()`. | | ||
| | `--enable-tools` | Registers a built-in `echo` tool (used by the `python-tools` example). Library users add their own tools via `SandboxBuilder::tool()`. | |
There was a problem hiding this comment.
Now that we'll have this feature, I think --enable-tools should no longer register the built-in echo tool. Instead, we replace that w/ two things: (1) a library usage example (prob a test?) showing how someone can register smt like an echo tool, and (2) we should update the python-tools example to use a echo tool coming from Wasm. For this, let's maybe an example/wasm-host-fns w/ some code that can be compiled to an echo.wasm or smt like that?
There was a problem hiding this comment.
I think this is still missing. Could you remove the hardcoded echo tool and make it a Wasm host function tool instead? Then, if it doesn't exist already, once we remove it, let's make sure there's still test coverage for registering host function tools like we did for the echo one too.
Signed-off-by: Akrm Al-Hakimi <alhakimiakrmj@gmail.com>
Signed-off-by: Akrm Al-Hakimi <alhakimiakrmj@gmail.com>
danbugs
left a comment
danbugs
left a comment
There was a problem hiding this comment.
Mostly LGTM. I think this should be good to merge after addressing the echo tool comment. Thanks!
| use std::path::PathBuf; | ||
|
|
||
| #[cfg(feature = "wasm-host-fns")] | ||
| mod wasm_host_fns; |
There was a problem hiding this comment.
This is private. I wonder if it should be available to the library too 🤔
This adds
--tool name=./handler.wasmsupport behind a newwasm-host-fnsCargo feature. The CLI now can register WASIp1 modules as custom host tools and route guest__dispatchcalls to them through the existingToolRegistrypath.Each Wasm tool is compiled and linked before the VM boots, then invoked as a fresh WASIp1 command per tool call. The handler gets the normal dispatch envelope on stdin,
{"name":"...","args":...}, and writes either a raw JSON result or a{"result": ...}/{"error": "..."}envelope to stdout. WASI filesystem and env access are capability-based and off by default, with explicit--tool-wasi-dir,--tool-wasi-dir-ro,--tool-wasi-env, and--tool-wasi-env-inheritflags. Calls also have fuel and stdout/stderr capture limits.Closes #84