Every time someone hands me a repo to look at - a take-home assignment, a PR from someone I've never worked with - "clone it and open it" already means giving that code a shot at running on my machine.
VS Code runs a task the second you open a folder if .vscode/tasks.json has runOn: folderOpen. npm install runs whatever's sitting in prepare or postinstall. A .devcontainer config gets to build and run its own Dockerfile the moment you click "reopen in container." None of that needs me to run anything by hand, it just needs me to open the folder.
sbx makes that operation boring. It clones the repo into a throwaway Docker container, attaches your actual VS Code / Cursor / Windsurf to it over Dev Containers, and gives that container no real secrets and no network access by default. Every DNS lookup and connection streams to your terminal live - an unknown host pauses and asks before it goes anywhere. There are also fake SSH keys and API tokens planted in the usual spots; touch one and the container pauses immediately, since nothing legitimate ever reads those files.
One Go binary, no daemon. sbx open <url> and you're in your editor.
Ctrl-C and the container, the checkout, all of it, is gone.
What it isn't: a VM. It shares your host kernel, so it's a namespace and firewall boundary, not a kernel-escape-proof wall. TLS to a host you've already allowed isn't inspected, so a secret could still leave over a connection you said yes to (that's the next thing I want to fix). VS Code-family editors only for now, no JetBrains yet.
https://github.com/giladno/sbx
Feedback on the threat model is what I actually want here - if you can see a way something gets out of the sandbox that I haven't accounted for, that's the bug report I'm hoping for before this has real users.
Top comments (0)