I am working on a personal project, I have already successfully built the core features of my entire project using Rust 1.93.0. Now, I am adding the final subsystem, an execution layer where agents can safely run generated code inside a WebAssembly sandbox with restricted File I/O and CPU fuel limits. But I recently hit the cap-primitives breakage on Windows (where Rust 1.94.0 added freeze_last_access_time and freeze_last_write_time to OpenOptionsExt, breaking older cap-std versions). To stabilize my build, I used a rust-toolchain.toml to pin the workspace to Rust 1.93.0.

However, navigating the wasmtime, wasmtime-wasi, and cap-std dependency matrix is getting messy. Older versions compile on 1.93.0 but lack newer WASI features, and newer versions expect Rust 1.94+ and cause trait resolution errors on Windows.

Current setup

wasmtime = "13.0.0"
wasmtime-wasi = "13.0.0"
cap-std = "1.0.0"

Sandbox requirements

• Mount restricted host directories (cap_std::fs::Dir)
• Limit CPU via fuel (config.consume_fuel(true))
• Capture stdout/stderr (pipes)

Problem

• Newer wasmtime / wasmtime-wasi versions (v20+) seem to require Rust ≥1.94 and fail on Windows due to trait mismatches
• Older versions (v13) compile but feel outdated and possibly lack newer WASI features

Questions

1. What is the recommended Wasmtime + WASI + cap-std version matrix that works reliably with Rust 1.93.0 on both Windows and Linux?
2. Is sticking with wasmtime-wasi v13 reasonable for a secure sandbox, or is it better to upgrade toolchain and move to the Component Model (v20+)?
3. Any known stable combinations used in production for similar sandboxing use cases?

Any guidance from folks would be massively appreciated!

1 post - 1 participant

Read full topic