Mapping Agent Sandbox Requirements To Web Primitives
Key takeaways
- In Co-do, the user selects a folder and configures an LLM provider and API key; the app then uses CSP-approved calls to interact with the provider and exposes tool-mediated access to the selected files through chat.
- A browser-based demo called Co-do was built to test whether an in-browser sandbox can enable agent-like coding workflows on local files.
- The corpus reports that iframe sandbox is thinly documented and behaves inconsistently enough across browsers to be a notable implementation pain point.
- The corpus frames a robust sandbox as a central requirement for coding agents to operate safely on user machines.
- The corpus suggests a browser-sandbox approach can feel comparable to Claude Cowork while avoiding the need to run a multi-gigabyte local container for isolation.
Sections
Mapping Agent Sandbox Requirements To Web Primitives
The corpus gives an explicit architecture: scoped file access, network egress restriction via CSP and iframe sandbox (with a double-iframe hardening pattern), and isolated code execution via WebAssembly in Web Workers, combined into a permissioned workflow for LLM calls and local file tooling.
- In Co-do, the user selects a folder and configures an LLM provider and API key; the app then uses CSP-approved calls to interact with the provider and exposes tool-mediated access to the selected files through chat.
- The corpus maps sandbox pillars to browser primitives: filesystem via the File System Access API, network restriction via CSP plus iframe sandbox, and safe code execution via WebAssembly in Web Workers.
- The corpus describes a double-iframe pattern intended to better apply network rules to an inner frame when using iframe sandbox with CSP.
Prototype Evidence For Composability
Beyond conceptual mapping, the corpus claims a concrete demo (Co-do) that composes these primitives into an agent-like experience, which reduces uncertainty about whether the pieces can coexist in a single browser application.
- A browser-based demo called Co-do was built to test whether an in-browser sandbox can enable agent-like coding workflows on local files.
- In Co-do, the user selects a folder and configures an LLM provider and API key; the app then uses CSP-approved calls to interact with the provider and exposes tool-mediated access to the selected files through chat.
- The corpus claims Co-do integrates the described browser sandboxing ideas into one application to illustrate an agent-like workflow in the browser.
Portability And Implementation Constraints
Two recurring bottlenecks are highlighted: read-write filesystem access is constrained by Chrome-only support for the File System Access API, and iframe sandbox is described as inconsistently behaved and under-documented. A partial mitigation is a cross-browser, read-only directory ingestion path via webkitdirectory.
- The corpus reports that iframe sandbox is thinly documented and behaves inconsistently enough across browsers to be a notable implementation pain point.
- The corpus states that input type="file" with webkitdirectory works in Firefox, Safari, and Chrome and enables read-only selection of an entire directory of files in the browser.
- The corpus states that the File System Access API is effectively Chrome-only at present, limiting cross-browser portability for full read-write filesystem sandbox designs.
Browser-As-Sandbox Mental Model
The corpus’ core delta is treating the browser not merely as a UI surface but as a mature security boundary suitable for running untrusted or semi-trusted agent tooling, with sandboxing positioned as a first-class design requirement.
- The corpus frames a robust sandbox as a central requirement for coding agents to operate safely on user machines.
- The corpus asserts that modern browsers are a decades-evolved sandbox optimized to execute hostile untrusted code from arbitrary origins on demand.
Expectations About Operational Overhead Vs Containers
The corpus sets an expectation that browser sandboxing can deliver a comparable experience to containerized isolation while avoiding multi-gigabyte local containers, but does not provide in-corpus measurements or comparative evaluations.
- The corpus suggests a browser-sandbox approach can feel comparable to Claude Cowork while avoiding the need to run a multi-gigabyte local container for isolation.
Unknowns
- What are the practical performance limits (file sizes, latency, concurrency) of the Co-do-style in-browser workflow across major browsers?
- How reliably do CSP and iframe sandbox configurations prevent unintended network egress across browsers, and what is the operational burden of validating that configuration?
- Will File System Access API portability change (e.g., broader browser support or altered permission models), and on what timeline?
- What capability gaps remain versus container-based sandboxes (tool execution breadth, offline operation, debugging ergonomics), and are they material for the intended agent workflows?
- What is the best supported cross-browser path for safe, scoped read-write project editing if File System Access API is unavailable?