zlacker

Note that you don't need to use Deno or JavaScript at all to use this product. Here's their Python client SDK: https://pypi.org/project/deno-sandbox/

  from deno_sandbox import DenoDeploy
  
  sdk = DenoDeploy()
  
  with sdk.sandbox.create() as sb:
      # Run a shell command
      process = sb.spawn("echo", args=["Hello from the sandbox!"])
      process.wait()
  
      # Write and read files
      sb.fs.write_text_file("/tmp/example.txt", "Hello, World!")
      content = sb.fs.read_text_file("/tmp/example.txt")
      print(content)

Looks like the API protocol itself uses websockets: https://tools.simonwillison.net/zip-wheel-explorer?package=d...

>>simonw+(OP)
Because the sandbox is on their cloud, not on your local machine, which wasn't obvious to me.

>>koakum+7i1
It's stated under the "Sandboxes?" heading.

> Deno Sandbox gives you lightweight Linux microVMs (running in the Deno Deploy cloud) ...

>>simonw+(OP)
Took this idea and ran with it using Fly's Sprites, inspired by Simon's https://simonwillison.net/2026/Feb/3/introducing-deno-sandbo.... Use case: Claude Code running in a sandboxed Sprite, making authenticated API calls via a Tokenizer proxy without credentials ever entering the sandbox.

Hit a snag: Sprites appear network-isolated from Fly's 6PN private mesh (fdf:: prefix inside the Sprite, not fdaa::; no .internal DNS). So a Tokenizer on a Fly Machine isn't directly reachable without public internet.

Asked on the Fly forum: https://community.fly.io/t/can-sprites-reach-internal-fly-se...

@tptacek's point upthread about controlling not just hosts but request structure is well taken - for AI agent sandboxing you'd want tight scoping on what the proxy will forward.