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

WASM runtime does not support shell commands. Use `execute_m

Error message

WASM runtime does not support shell commands. Use `execute_module()` to run WASM tools, or switch to runtime.kind = "native" for shell access.

What it means

WasmPlatform implements the platform trait's build_shell_command by immediately bailing. The WASM sandbox is deliberately shell-less — tools must be compiled .wasm modules executed via execute_module, so no tokio process Command can be constructed. The message points callers to the two supported alternatives: execute_module for wasm tools, or runtime.kind = "native" when shell access is genuinely required.

Source

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

    fn supports_long_running(&self) -> bool {
        // WASM modules are short-lived invocations, not daemons
        false
    }

    fn memory_budget(&self) -> u64 {
        self.config.memory_limit_mb.saturating_mul(1024 * 1024)
    }

    fn shell_dialect(&self) -> ShellDialect {
        ShellDialect::None
    }

    fn build_shell_command(
        &self,
        _command: &str,
        _workspace_dir: &Path,
    ) -> anyhow::Result<tokio::process::Command> {
        bail!(
            "WASM runtime does not support shell commands. \
             Use `execute_module()` to run WASM tools, or switch to runtime.kind = \"native\" for shell access."
        )
    }
}

// ── Tests ───────────────────────────────────────────────────────

#[cfg(test)]
mod tests {
    use super::*;

    fn default_config() -> WasmRuntimeConfig {
        WasmRuntimeConfig::default()
    }

    // ── Basic trait compliance ──────────────────────────────────

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Port the tool to a wasm module and invoke it with execute_module()
2. If shell access is a hard requirement, switch config to runtime.kind = "native" for that deployment
3. Guard shell-dependent code paths: branch on the platform/runtime kind before ever calling build_shell_command
4. Audit skills/plugins for shell usage before enabling the wasm runtime

Example fix

// before
let cmd = platform.build_shell_command("ls -la", &ws)?;

// after
match platform_kind {
    RuntimeKind::Native => platform.build_shell_command("ls -la", &ws)?,
    RuntimeKind::Wasm => { platform.execute_module("lister", &ws, &caps)?; /* ... */ }
}

match platform.runtime_kind() {
    RuntimeKind::Native => { let cmd = platform.build_shell_command(cmd_str, &ws)?; }
    RuntimeKind::Wasm => { /* route to execute_module with a compiled tool instead */ }
}

Err(e) if e.to_string().contains("does not support shell commands") => {
    // architectural limit of the sandbox: port the tool to wasm or switch runtime.kind; never bypass
}

When it happens

Trigger: Any code path that builds a shell command (tool executors that `sh -c` skill instructions, legacy bash-tool call sites) while the configured platform is the WASM one; skills or plugins assuming a native host; runtime kind switched to wasm without auditing shell-dependent features.

Common situations: Hardening a deployment into the wasm sandbox without refactoring bash-based tools; shared skill packs written against the native runtime; new contributors testing skills on a wasm-configured instance.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• runtime.wasm.memory_limit_mb must be > 0
• 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 not found: {} (looked in {})

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