ClawLess: A Browser-Only Runtime for Claw Agents, Built on WebContainers

The problem ClawLess targets: agent execution without a sandbox host

Running an AI agent that writes and executes code normally means standing up an execution environment somewhere: a container host, a VM, a function with a writable filesystem. That environment has to be isolated from everything else, monitored, and paid for even when idle. ClawLess removes that host from the picture. The README describes it as a serverless browser-based runtime for Claw AI Agents powered by WebContainers, and the claim it makes is specific: run Claw Agents without a server, entirely on-browser via WebContainers (WASM). The audience is developers building agent tooling who want the execution sandbox to be the user's own browser tab. That framing matters because it changes the deployment story completely. There is no container image to build, no orchestration layer, and no server-side process to keep alive between sessions. The README also states the sandbox has no access to the host system, which is the property that makes a browser tab an acceptable place to run generated code in the first place.

What actually runs inside the tab: WebContainer, Monaco, xterm.js and the policy engine

The README lists the moving parts plainly. A WebContainer provides a full Node.js environment in the browser through WebAssembly, and the project claims access to 3.4 million plus npm packages as a consequence. On top of that runtime sit four user-facing components: Monaco Editor with multi-file tabs, an xterm.js terminal described as having full PTY support, a YAML policy engine, and an audit log. The architecture table in the README names the internal pieces. ClawContainer is the SDK facade and the single entry point for consumers. ContainerManager handles WebContainer orchestration and lifecycle. PolicyEngine enforces file, process and network rules from YAML. AuditLog records every action inside the container. GitService talks to the GitHub API for clone and push. The README also mentions a plugin system with lifecycle hooks, a template system for agent configurations, and network interception covering both browser fetch and Node.js http calls. The data flow implied by the material is: the SDK boots a WebContainer from a template, the agent issues file and process operations, the policy engine evaluates each against YAML rules, the audit log records the outcome, and the editor and terminal render the state. What is not documented in the supplied material is how the policy engine resolves a rule conflict or what happens when a policy is applied mid-execution to a process that is already running.

Getting it running: two install paths and the SDK entry point

The README gives two ways in. To run the project locally, clone the repository, install dependencies and start the dev server:

git clone https://github.com/open-gitagent/clawless.git cd clawless npm install npm run dev

To consume it as a library, the package is published as clawcontainer:

npm install clawcontainer

The SDK example in the README constructs a ClawContainer against a DOM selector and passes a template name and environment variables:

import { ClawContainer } from 'clawcontainer';

const cc = new ClawContainer('#app', { template: 'gitclaw', env: { ANTHROPIC_API_KEY: 'sk-...' } });

await cc.start(); cc.on('ready', () => console.log('Container ready!'));

Two config keys are visible here: template, which selects a bootstrap preset, and env, which carries provider credentials into the container. The README lists Anthropic, OpenAI and Google as supported providers, so the ANTHROPIC_API_KEY in the example is one of three options rather than the only one. The 'ready' event is the documented signal that the container has finished starting. Note that the env object places an API key inside a browser-side runtime. The README says sensitive headers like API keys are automatically masked in the audit log, which addresses log exposure, but the key is still present in the page context, and the material does not describe a proxy or key-exchange mechanism.

The policy engine is the part worth evaluating closely

Most browser sandboxes stop at isolation. ClawLess layers a declarative policy engine on top, and the README is explicit about what it controls: file access rules, allowed processes, port bindings, and runtime limits including max file size, max processes, max turns and timeout. Policies are written in YAML and matched with glob patterns. The README states that policies are enforced at the container level, so agents cannot bypass them, and that policies can be applied or reset on the fly without restarting the container. That last property is the interesting one, because it means a long-running agent session can be tightened after it starts. The concrete limitation is that this is a guardrail system, not a capability system. It constrains what the agent may do inside the WebContainer; it does not change what the WebContainer itself can do. If a rule forbids binding a port, the agent cannot bind it. If the runtime does not support a syscall in the first place, no policy makes it available. The README does not publish the full set of policy keys beyond the ones named, so anyone planning to encode a specific rule should read DOCS.md rather than infer the schema from the feature list.

Audit logging and the masking claim

The audit log is described as capturing process lifecycle, file I/O, network requests and responses, environment configuration, and policy enforcement. The README says entries are filterable by source, level or event type, and that the full log can be downloaded. It also states that sensitive headers such as API keys are automatically masked. Two things are worth separating here. First, masking is scoped to headers in the log, not to the runtime environment, so the claim should not be read as credential protection generally. Second, the audit log lives in the browser alongside the agent. That is convenient for debugging and for handing a session record to someone else, but it means the log is only as durable as the tab. The material does not describe a server-side sink, retention policy, or tamper resistance, so treating this as a compliance artifact requires an export step that the README mentions but does not detail beyond a download action. The screenshots referenced in the README show process spawns, file writes and network requests appearing as filterable entries, which is the level of granularity the project is aiming at.

Where ClawLess is the wrong tool

The constraints follow directly from the architecture. Everything runs in WebAssembly inside a browser tab, so anything requiring native binaries, kernel features, Docker, or GPU access is out of scope. Workloads that must run without a human present are also out of scope, because a browser tab is not a scheduler. If you need an agent to run at 3am and write results to a database, ClawLess is not the runtime for that. Resource ceilings apply too: the README names max processes, max file size and timeout as policy-controlled limits, which is an admission that the sandbox has finite headroom. The README's own example is an agent installing pptxgenjs and generating a PowerPoint file, which is a reasonable picture of the intended workload: Node packages, file generation, in-browser preview. Anything heavier should be tested against those limits before you commit. There is also the question of what the WebContainer runtime supports at the syscall level, which the supplied material does not enumerate. If your agent depends on a specific Node API, verify it runs before designing around ClawLess.

The alternative: server-side container sandboxes

The obvious comparison is a server-side sandbox, whether that is a container runtime on your own infrastructure or a hosted code-execution API. The difference in approach is where the trust boundary sits and who pays for it. A server-side sandbox gives the agent a real Linux environment with native binaries, background execution, and persistent storage, and it can be driven by cron or a queue. ClawLess gives up all of that in exchange for removing the host entirely and putting the sandbox inside the user's tab, where the README states there is no access to the host system. The cost model differs as well: a server-side sandbox bills for compute you provision, while ClawLess pushes execution onto the client. The observability story is the sharper contrast. A server-side sandbox typically centralizes logs where an operator can read them; ClawLess writes the audit trail into the browser and offers a download. If your requirement is centralized, tamper-evident logging across many agent sessions, the browser-side model works against you. If your requirement is that generated code never executes on your infrastructure at all, it works for you.

Maintenance, licence and what to check before adopting

ClawLess is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive arrangement, but it is not legal advice, and anyone embedding the SDK in a product should confirm the obligations against their own counsel. The practical maintenance question is dependency depth. ClawLess sits on WebContainers, which is a third-party runtime, and its feature set is bounded by what that runtime exposes. Upgrades to the underlying runtime are therefore upgrades to ClawLess's capabilities and risks at the same time. The repository shows a single release, v1.0.0, dated 2026-03-19, with the last push in July 2026, so the project is young and the API surface should be treated as movable. TypeScript 5.4 is the language baseline per the README badges. The template system is another maintenance point: the SDK example depends on a template named gitclaw, and the README describes templates as reusable presets for bootstrapping agents, so a template change is a breaking change for anyone who hardcoded its name. Before adopting, read DOCS.md for the full policy schema, confirm which templates ship in the repository, and check whether the WebContainer cross-origin isolation requirements are satisfied by your hosting environment, because that is a precondition ClawLess inherits rather than solves.

Editorial conclusion

Adopt ClawLess when the agent workload is Node-based, the code never needs to leave the browser, and you want a policy layer and audit trail without operating a sandbox host. Do not adopt it if your agents shell out to native binaries, need Docker, need GPU access, or must run headless on a schedule. Before committing, verify that the template you intend to use exists in the repository, that your chosen model provider is one of the three listed, and that the WebContainer cross-origin isolation requirements are met in your hosting setup, since ClawLess inherits those constraints rather than removing them.

Official sources

1. License: MIT
2. open-gitagent/clawless on GitHub
3. Project website
4. README
5. Releases