Browser Sandbox Model: Simon Willison's Co-do Demo and In-Browser Isolation

Simon Willison's latest take on browser security argues that the browser itself can be the sandbox we need for running untrusted code. His post, The browser is the sandbox, centers on a demo called Co-do and asks a broader question: could we run software like Cowork inside the browser with strong isolation from the host machine? This matters because it reframes how we think about running code that touches local files, network access, and computation without surrendering control to a native OS boundary. If the browser can reliably isolate hostile input, we suddenly have a portable, user-initiated execution environment that stays inside the user's browser.

The three-part sandboxing model

The idea rests on a three-part sandboxing model that the browser already implements in practice. First up is safe filesystem access via the File System Access API, which lets web apps read and write user files with explicit permission. Next comes network and API access, bounded by the browser’s normal security model and CSP rules. Finally, safe code execution comes from isolation primitives like WebAssembly in Web Workers, which prevents untrusted code from touching the main thread or the user’s data. Chrome leads in File System Access API for now, while CSP headers with iframe sandbox and WebAssembly in Web Workers are the other two pieces Co-do uses to demonstrate restricted interaction with a provider and a chat interface.

Co-do demo in practice

Co-do embodies the idea in a compact, single-app demo. You pick a folder full of files, set up an API provider and key, and the app makes CSP-approved calls to that provider while presenting a chat-like interface. This isn't a product; it's a demonstration that the browser can host a workflow that would have once needed a native component or a looser run-time. The browser becomes the sandbox where untrusted code can run with clear permissions and boundaries, shrinking the attack surface versus traditional desktop apps.

Developer takeaways and cross-browser considerations

For developers, this raises practical questions. If you can rely on a browser sandbox to handle filesystem access and restricted computation, you can ship offline-friendly experiences that still respect user consent and data locality. The approach also changes how tooling that needs local resources gets distributed, without uploading everything to a server. Right now, support is uneven: File System Access API exists, but Chrome leads, and other engines lag behind. In practice you’ll want to design around CSP sandbox constraints and WebAssembly in workers, while tracking cross-browser compatibility as these APIs mature.

The browser is the sandbox Google Developers Web File System Access API CSP sandbox directive WebAssembly in Workers