the browser is the sandbox

Simon Willison’s Weblog
Subscribe

the browser is the sandbox. Paul Kinlan is a web platform developer advocate at Google and recently turned his attention to coding agents. He quickly identified the importance of a robust sandbox for agents to operate in and put together these detailed notes on how the web browser can help:

This got me thinking about the browser. Over the last 30 years, we have built a sandbox specifically designed to run incredibly hostile, untrusted code from anywhere on the web, the instant a user taps a URL. [...]
Could you build something like Cowork in the browser? Maybe. To find out, I built a demo called Co-do that tests this hypothesis. In this post I want to discuss the research I've done to see how far we can get, and determine if the browser's ability to run untrusted code is useful (and good enough) for enabling software to do more for us directly on our computer.

Paul then describes how the three key aspects of a sandbox - filesystem, network access and safe code execution - can be handled by browser technologies: the File System Access API (still Chrome-only as far as I can tell), CSP headers with <iframe sandbox> and WebAssembly in Web Workers.
Co-do is a very interesting demo that illustrates all of these ideas in a single application:

You select a folder full of files and configure an LLM provider and set an API key, Co-do then uses CSP-approved API calls to interact with that provider and provides a chat interface with tools for interacting with those files. It does indeed feel similar to Claude Cowork but without running a multi-GB local container to provide the sandbox.
My biggest complaint about <iframe sandbox> remains how thinly documented it is, especially across different browsers. Paul's post has all sorts of useful details on that which I've not encountered elsewhere, including a complex double-iframe technique to help apply network rules to the inner of the two frames.
Thanks to this post I also learned about the <input type="file" webkitdirectory> tag which turns out to work on Firefox, Safari and Chrome and allows a browser read-only access to a full directory of files at once. I had Claude knock up a webkitdirectory demo to try it out and I'll certainly be using it for projects in the future.

Posted 25th January 2026 at 11:51 pm

Recent articles

Wilson Lin on FastRender: a browser built by thousands of parallel agents - 23rd January 2026
First impressions of Claude Cowork, Anthropic's general agent - 12th January 2026
My answers to the questions I posed about porting open source code with LLMs - 11th January 2026

browsers
96

javascript
738

sandboxing
30

ai
1799

generative-ai
1592

llms
1557

ai-agents
95

coding-agents
131

claude-code
81

Monthly briefing

Sponsor me for $10/month and get a curated email digest of the month's most important LLM developments.

Pay me to send you less!

Sponsor & subscribe

Colophon
©
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026

This article details an exploration by Simon Willison into the potential of web browsers as robust sandboxes for running untrusted code, specifically within the context of developing software agents like Claude Cowork. The central thesis revolves around leveraging existing browser technologies – namely the File System Access API, Content Security Policy (CSP) with `<iframe sandbox>` attributes, and WebAssembly in Web Workers – to provide a secure environment for external software to interact with a user’s computer. The analysis underscores the browser’s established history of handling hostile code from across the internet, essentially presenting a pre-existing, highly effective sandbox.

The core of Willison’s investigation revolves around a demonstration application called Co-do. This application allows users to select a folder containing files and then configure an LLM (Large Language Model) provider, complete with an API key. Co-do then utilizes CSP-approved API calls to communicate with the chosen LLM provider, offering a chat interface alongside tools for interacting directly with the selected files within the folder. This setup strikingly mirrors the functionality of Claude Cowork, but crucially, it achieves this without requiring the substantial computational resources typically associated with running a multi-gigabyte local container.

A significant element of this research is the examination of browser features and their application within the sandbox environment. Willison highlights the complexities of utilizing CSP, particularly the double-iframe technique, which he describes as a method to apply network rules effectively to the inner frame of a two-frame setup. This demonstrates a sophisticated understanding of browser security mechanisms and their adaptability to complex scenarios.

Furthermore, the post introduces the `<input type="file" webkitdirectory>` tag, emphasizing its operational functionality across Firefox, Safari, and Chrome. This tag enables a browser-level, read-only access to an entire directory of files, representing a practical and easily implementable addition to the sandbox architecture. Willison’s use of this feature, facilitated through a demo built by Claude, indicates an intention to integrate it into future projects.

The article positions the browser as a surprisingly adaptable platform for developing and deploying sophisticated AI agents. The post’s emphasis on the browser’s pre-existing capacity for handling and controlling untrusted code suggests that it represents a viable, and potentially superior, alternative to traditional containerized approaches for running such applications. The document clearly advocates for a deeper investigation into the capabilities of the browser as a secure and efficient operating environment for AI agents, highlighting the importance of technologies like CSP and File System Access API. The exploration underscores the relevance of browser technologies in the evolving landscape of generative AI and software agent development, specifically its ability to act as a fortified environment for external code execution.