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

  1. Set memory_limit_mb to a positive value appropriate for your tools (e.g. 64–256)
  2. If you meant "no artificial cap", use the maximum supported value 4096 rather than 0
  3. If you meant "disable WASM", change the runtime kind (native) instead of zeroing limits
  4. 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

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


AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/b365121f8100acbe. Report an issue: GitHub.