Nice, what are you building exactly ?

We are building cloud-native agent harnesses.

I am in the EU timezone and had some minor issues recently with GitHub as well, but it never lasts very long.

The worst that could happen is having your credentials stolen. It’s an LLM architectural flaw, so it has to be at the tools level so the only way to prevent it is still sandboxing in my opinion. Or at least sandboxing the tools themselves

I think a shared array just avoids the copy, not the serialization which is the main problem as they showed with serde-wasm-bindgen test

You can avoid the serialization in WASM by pushing structured bytes to the SharedArrayBuffer, then do serialization in JS which should be relatively cheap compared to pushing JSON strings across the boundary.

Wait, you just invented a reverse CAPTCHA for AI agent

The ole' click this button 10,000 times to prove you're a bot, eh?

That’s great, but it can’t be used in production because it’s not available for Linux (so no AWS, no GCP, etc.) and requires Docker Desktop. Still nice for experimenting, though.

I mean standardizing on an x86 subset would replace wasm's native portability with a kind of 'emulated' compatibility, and this is one of wasm's strengths. If we do that, non-x86 hardware(mobile etc.) will pay the translation tax. So, keeping Wasm agnostic makes more sense anyway.

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.