zeroclaw-labs/zeroclaw · error · anyhow::Error
runtime.wasm.memory_limit_mb must be > 0
Error message
runtime.wasm.memory_limit_mb must be > 0
What it means
WasmPlatform::validate_config sanity-checks the runtime.wasm settings before the WASM sandbox is used. memory_limit_mb becomes the memory store cap for executed modules; a value of 0 would instantiate modules with no linear memory, so it is rejected up front with this message. The check is a cheap misconfiguration guard, not a runtime failure.
Source
Thrown at crates/zeroclaw-runtime/src/platform/wasm.rs:68
}
/// Create a WASM runtime bound to a specific workspace directory.
pub fn with_workspace(config: WasmRuntimeConfig, workspace_dir: PathBuf) -> Self {
Self {
config,
workspace_dir: Some(workspace_dir),
}
}
/// Check if the WASM runtime feature is available in this build.
pub fn is_available() -> bool {
cfg!(feature = "runtime-wasm")
}
/// Validate the WASM config for common misconfigurations.
pub fn validate_config(&self) -> Result<()> {
if self.config.memory_limit_mb == 0 {
bail!("runtime.wasm.memory_limit_mb must be > 0");
}
if self.config.memory_limit_mb > 4096 {
bail!(
"runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety limit for 32-bit WASM",
self.config.memory_limit_mb
);
}
if self.config.tools_dir.is_empty() {
bail!("runtime.wasm.tools_dir cannot be empty");
}
// Verify tools directory doesn't escape workspace
if self.config.tools_dir.contains("..") {
bail!("runtime.wasm.tools_dir must not contain '..' path traversal");
}
Ok(())
}
/// Resolve the absolute path to the WASM tools directory.View on GitHub (pinned to 88bb9c8533)
Solutions
- Set memory_limit_mb to a positive value appropriate for your tools (e.g. 64–256)
- If you meant "no artificial cap", use the maximum supported value 4096 rather than 0
- If you meant "disable WASM", change the runtime kind (native) instead of zeroing limits
- Call validate_config() right after loading config so this surfaces at startup, not mid-execution
Example fix
# before [runtime.wasm] memory_limit_mb = 0 # after [runtime.wasm] memory_limit_mb = 256
Defensive patterns
Strategy: validation
Validate before calling
fn check_wasm_memory(cfg: &WasmConfig) -> Result<(), String> {
(cfg.memory_limit_mb > 0)
.then_some(())
.ok_or_else(|| "runtime.wasm.memory_limit_mb must be > 0".into())
}
// run after config load, before first execute_module Try / catch
if let Err(e) = platform.validate_config() {
// startup-time config error: report and exit; retrying without changing config is pointless
} Prevention
- Call validate_config() immediately after loading config so misconfigurations fail at boot, not mid-run
- Generate wasm config from a known-good template that always sets memory_limit_mb
- Assert config validity in integration tests for every shipped example config
When it happens
Trigger: Explicitly setting runtime.wasm.memory_limit_mb = 0 (perhaps intending "unlimited" or "disabled"); a config template defaulting the field to 0; deserialized older config where the field was absent and zero-valued.
Common situations: Copy-pasting minimal config snippets that omit the field when the type default is 0; users trying to disable the memory cap by zeroing it; automation writing 0 before filling a real value.
Understand the failure class
Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.
Related errors
- runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety l
- runtime.wasm.tools_dir cannot be empty
- runtime.wasm.tools_dir must not contain '..' path traversal
- WASM module {} is {} MB — exceeds 50 MB safety limit
- cloud_ops.iac_tools must not be empty when cloud_ops is enab
AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23).
Data as JSON: /api/errors/b365121f8100acbe.
Report an issue: GitHub.