Thanks! Not yet, but that's a great idea. I could definitely add it to the roadmap.

I would love for the component model tooling to reach that level of maturity.

Since the runtime uses standard WASI and not Emscripten, we don't have that seamless dynamic linking yet. It will be interesting to see how the WASI path eventually converges with what Pyodide can do today regarding C-extensions.

Thanks for the feedback! What do you think about running the separate file directly from the decorator?

I'd love that. I want to be able to look at the system and 100% understand which code is running directly and which code is running inside the sandbox.

Thanks! Got it, I will add more examples for that. Currently you can do both: run dynamically untrusted code with eval, or run fully encapsulated logic (like in the existing examples).

I made a small example that might give you a better idea (it's not eval, but shows how to isolate a specific data processing task): https://github.com/mavdol/capsule/tree/main/examples/javascr...

And yes, you are spot on regarding LeetCode platforms. The resource limits are also designed for that kind of usage.

Would like to see the eval version - the dialogue version just seems like normal code with extra steps?

yeah, the previous example was quite basic. I will write a complete example for that, but here is how you can run dynamic code:

   import { task } from "@capsule-run/sdk";

   export default task({
     name: "main",
     compute: "HIGH",
   }, async () => {
     const untrustedCode = "const x = 10; x * 2 + 5;";
     const result = eval(untrustedCode);
     return result;
   });

Hope that helps!

Is the code in the eval also turned into wasm first then? Does this work as a JIT for wasm?

It actually works a bit differently. The eval is executed by the interpreter running inside the isolated wasm sandbox (StarlingMonkey). You can think of it as each sandbox having its own dedicated JavaScript engine.

yep, more examples with agents use will be helpful

I understand your point. I added native Python support because C extensions will eventually become compatible. Also, we might see more libraries built with Rust extensions appearing, which will be much easier to port to Wasm.

I recreated many Node.js built-ins so compatibility is actually quite extended.

For Python, the main limitation is indeed C extensions. I'm looking for solutions. the move to WASI 0.3 will certainly help with that.

Yep, exactly.

We stick to JSON to make sure we pass data, not behavior. It avoids all that complexity.

I see what you mean, but i think there is room for both approaches.

If we want to isolate untrusted code at a very fine-grained level (like just a specific function), VMs can feel a bit heavy due to the overhead, complexity etc

What you really want to do is decouple the sandbox specification annotations from the sandbox implementation backend, yes?

Actually, since it runs inside a WASM sandbox, even if the untrusted code overwrites built-ins like map or modifies globals(), it only affects its own isolated memory space. It cannot escape the WASM container or affect the host system

yep, and to be specific, it leverages the WASM Component Model and uses componentize-py to bundle the user's script