zeroclaw-labs/zeroclaw · error · anyhow::Error
runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety l
Error message
runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety limit for 32-bit WASM What it means
The second WASM config guard: memory_limit_mb above 4096 is rejected because it exceeds the 4 GB address space of 32-bit WASM memories. A limit larger than what a wasm32 module can ever address is either a unit mistake (bits vs bytes, MB vs GB) or a mispaste, so validate_config refuses it rather than silently clamping.
Source
Thrown at crates/zeroclaw-runtime/src/platform/wasm.rs:71
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.
pub fn tools_dir(&self, workspace_dir: &Path) -> PathBuf {
workspace_dir.join(&self.config.tools_dir)
}View on GitHub (pinned to 88bb9c8533)
Solutions
- Cap the setting at 4096 or below — for wasm32 that is the entire addressable maximum anyway
- Double-check units: the field is megabytes, so 4096 already means 4 GB
- If a tool genuinely needs more memory than 4 GB, it cannot run as a 32-bit WASM module — run it under runtime.kind = "native"
- Keep the value realistic for actual modules (most tools need tens to hundreds of MB)
Example fix
# before [runtime.wasm] memory_limit_mb = 16384 # after [runtime.wasm] memory_limit_mb = 512
Defensive patterns
Strategy: validation
Validate before calling
const MAX_WASM_MB: u32 = 4096;
if cfg.memory_limit_mb > MAX_WASM_MB {
// reject at config load with a unit hint (field is megabytes; 4096 == 4 GB == wasm32 max)
} Try / catch
if let Err(e) = platform.validate_config() {
if e.to_string().contains("4 GB safety limit") {
// unit/typo problem: clamp to <=4096 or move the workload to native runtime
}
} Prevention
- Treat >4096 as a unit mistake by default — the field is MB, not bytes
- Keep wasm tool memory budgets in the tens-to-hundreds of MB
- If a tool needs >4 GB, it belongs on the native runtime, not wasm32
When it happens
Trigger: Setting memory_limit_mb = 8192 or 16384 copying native-container habits; entering a byte count (4294967296) instead of megabytes; upgrading configs from systems that expressed limits differently.
Common situations: Teams used to 64-bit native runtimes requesting tens of GB; unit confusion between MiB/GB; values pasted from infrastructure docs for container memory limits.
Related errors
- runtime.wasm.memory_limit_mb must be > 0
- 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/81c161b6a036a4a7.
Report an issue: GitHub.