zeroclaw-labs/zeroclaw · error · anyhow::Error

WASM runtime is not available in this build. Rebuild with `c

Error message

WASM runtime is not available in this build. Rebuild with `cargo build --features runtime-wasm` to enable WASM sandbox support. Module requested: {module_name}

What it means

When the zeroclaw-runtime is compiled without the runtime-wasm cargo feature, WasmPlatform::execute_module is a stub whose only body is this bail: it names the missing feature, the rebuild command, and the requested module. This keeps the platform API compilable in slim builds while making any accidental WASM-tool invocation a loud, actionable error instead of a silent no-op.

Source

Thrown at crates/zeroclaw-runtime/src/platform/wasm.rs:231

        let fuel_consumed = fuel_before.saturating_sub(fuel_after);

        Ok(WasmExecutionResult {
            stdout: String::new(),  // No WASI stdout yet — pure computation
            stderr: String::new(),
            exit_code,
            fuel_consumed,
        })
    }

    /// Stub for when the `runtime-wasm` feature is not enabled.
    #[cfg(not(feature = "runtime-wasm"))]
    pub fn execute_module(
        &self,
        module_name: &str,
        _workspace_dir: &Path,
        _caps: &WasmCapabilities,
    ) -> Result<WasmExecutionResult> {
        bail!(
            "WASM runtime is not available in this build. \
             Rebuild with `cargo build --features runtime-wasm` to enable WASM sandbox support. \
             Module requested: {module_name}"
        )
    }

    /// List available WASM tool modules in the tools directory.
    pub fn list_modules(&self, workspace_dir: &Path) -> Result<Vec<String>> {
        let tools_path = self.tools_dir(workspace_dir);
        if !tools_path.exists() {
            return Ok(Vec::new());
        }

        let mut modules = Vec::new();
        for entry in std::fs::read_dir(&tools_path)
            .with_context(|| format!("Failed to read tools dir: {}", tools_path.display().to_string()))?
        {
            let entry = entry?;

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Rebuild with the feature: cargo build --features runtime-wasm (or add it to your build script/install command for zeroclaw)
  2. If installing from a package, pick the variant that includes wasm support
  3. If wasm tools are not needed in this deployment, stop invoking them — use native runtime tooling instead
  4. Gate wasm tool paths in your own code with cfg!(feature = "runtime-wasm") so the failure is compile-time visible

Example fix

# before
cargo build --release

# after
cargo build --release --features runtime-wasm
Defensive patterns

Strategy: validation

Validate before calling

if !cfg!(feature = "runtime-wasm") {
    // compile-time known: skip/disable wasm tool paths instead of calling execute_module
    return Ok(default_without_wasm_tools());
}

Try / catch

Err(e) if e.to_string().contains("not available in this build") => {
    // deployment mismatch: rebuild with --features runtime-wasm or drop the wasm tool path
}

Prevention

When it happens

Trigger: Running the default/slim zeroclaw build and invoking a wasm tool; deploying a package built without --features runtime-wasm; a dependency pulling in zeroclaw-runtime with default features and calling execute_module.

Common situations: Distro/package-manager builds that strip heavy optional dependencies (wasmer); Docker images built with a minimal feature set; upgrading from a full-featured build to a slim one without realizing tools were wasm-based.

Related errors

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