PR #91 introduced --tool-wasi-* CLI flags for configuring Wasm tool sandboxes (filesystem preopens, env vars, fuel, output limits). Currently, these settings apply globally to every --tool registered in one invocation — all tools share the same filesystem grants, env, fuel budget, and output cap.
This means operators who need tools with different privilege levels must either grant the union of all permissions to every tool, or run separate host processes. Neither is ideal.
A per-tool configuration surface would allow something like:
--tool reader=reader.wasm --tool-wasi-dir[reader] /data:/data --tool-wasi-dir-ro[reader] /config:/config
--tool writer=writer.wasm --tool-wasi-dir[writer] /output:/output --tool-wasi-fuel[writer] 50000000
This is a design question more than a straightforward feature — the CLI ergonomics, config file support, and interaction with a potential future WASIp2 multi-tool model (#92) all need consideration.
PR #91 introduced
--tool-wasi-*CLI flags for configuring Wasm tool sandboxes (filesystem preopens, env vars, fuel, output limits). Currently, these settings apply globally to every--toolregistered in one invocation — all tools share the same filesystem grants, env, fuel budget, and output cap.This means operators who need tools with different privilege levels must either grant the union of all permissions to every tool, or run separate host processes. Neither is ideal.
A per-tool configuration surface would allow something like:
This is a design question more than a straightforward feature — the CLI ergonomics, config file support, and interaction with a potential future WASIp2 multi-tool model (#92) all need consideration.