ClawLess: Running Claw AI Agents in the Browser with WebContainers

The problem ClawLess targets: an agent that must not touch your machine

Most agent runtimes assume a server. You provision a container, mount a workspace, hand the agent a shell, and then spend the rest of the week deciding how much of that container the agent is allowed to reach. ClawLess inverts the arrangement. The runtime is a browser tab, the filesystem is a virtual one owned by WebContainers, and the isolation comes from WASM rather than from a hypervisor. The README states the pitch plainly: "No server required to run Claw Agents, use ClawLess to run on browser!"

The audience is narrow and specific. It suits people building demos, teaching environments, or internal tools where an agent writes and executes Node.js code and the operator wants a visible record of what happened. The README's screenshots show exactly that shape of work: an agent installing pptxgenjs to build a slide deck, and an agent writing and previewing a calculator app, both inside the sandbox.

It does not suit anyone who needs the agent to reach a real host, install native dependencies, or persist work beyond the life of the tab. Those are not gaps in the implementation; they are consequences of choosing the browser as the execution substrate.

How the WebContainer runtime, PolicyEngine and AuditLog fit together

The architecture table in the README names five components. 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 written in YAML. AuditLog records every action inside the container. GitService talks to the GitHub API for clone and push. The README's table is truncated at the GitService row, so the remaining entries are not visible.

The dependency list in package.json confirms the substrate. @webcontainer/api is the runtime, monaco-editor provides the multi-file editor, @xterm/xterm and @xterm/addon-fit provide the terminal, and jszip is present for archive handling. There is no server-side framework in the dependency list, which is consistent with the claim that nothing runs on a backend.

Policy enforcement happens at the container level, and the README is explicit that agents cannot bypass it. Policies can be applied or reset while the container runs, without a restart. That is a meaningful design choice: you can tighten the rules after watching an agent behave badly, rather than tearing down the sandbox and losing its filesystem state.

Audit logging is the other half. The README says process lifecycle, file I/O, network requests and responses, environment configuration and policy enforcement are all captured, that sensitive headers such as API keys are masked automatically, and that logs can be filtered by source, level or event type and downloaded. Network interception covers both browser fetch and Node.js http calls, which matters because an agent that can only be observed at one of those layers is only half observed.

Installing ClawLess and running a first container

There are two paths in the README. The first is running the project itself locally, which is what you want if you are evaluating the UI before writing any code against it.

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

npm run dev maps to vite, so you should get a local development server serving the app. The README does not state which port Vite picks, so read the terminal output rather than assuming one.

The second path is consuming the SDK as a dependency. The package is published as clawcontainer, not as clawless, which is the detail most likely to trip someone up.

npm install clawcontainer

The README's SDK example constructs a container against a CSS selector, passes a template name and an environment variable, starts it, and waits for a ready event.

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!'));

When the ready event fires, the container is up and the agent can begin work. The template value gitclaw is the only template name the README shows; the documentation file DOCS.md is where the full template list would live. Multi-provider support for Anthropic, OpenAI and Google is listed as a feature, so the environment variable you pass will depend on which provider you intend to use.

Where ClawLess stops being the right tool

The browser is the constraint, and it shows up in several places.

WebContainers are a browser capability. The README does not enumerate supported browsers, and the badge only says "platform: browser". Anything that depends on a specific browser engine, or on a user who has disabled the relevant APIs, is outside what this project can promise.

Long-running work is a poor fit. A sandbox that lives in a tab ends when the tab ends. An agent that needs to poll an external service for hours, or hold a session across a laptop sleep, is fighting the substrate rather than using it.

Native binaries are out. The README's own example of the runtime's reach is npm: it states that WebContainers give access to "3.4 million+ npm packages". That is a statement about JavaScript packages, not about arbitrary system software. An agent whose job is to compile a C extension, run a database server, or shell out to a system utility is not what this runtime was built for.

Finally, the isolation cuts both ways. The README lists "no access to the host system" as a security property, and it is one. It also means the agent cannot read a file you forgot to upload, cannot reach a service bound to localhost on your machine, and cannot use credentials you have not explicitly placed in its environment.

ClawLess compared with running agents in a server-side container

The obvious alternative is a conventional container runtime on a server: Docker, a Kubernetes pod, or a hosted sandbox service. The difference is not one of degree but of where the boundary sits.

With a server-side container, the agent's filesystem is a real filesystem on a real kernel, network access is real network access, and the isolation boundary is the container runtime plus whatever seccomp or AppArmor profile you attach. You get native binaries, long-running processes, and persistent volumes. You also get a deployment, an image to patch, and a machine that someone must keep alive.

With ClawLess, the boundary is the browser's WASM sandbox. There is nothing to deploy because there is no server, and the agent's blast radius is the virtual filesystem inside the tab. The trade is capability: you give up native execution and durable background work in exchange for a runtime that a user can open like a web page.

There is a second, subtler difference in observability. A server-side container typically logs at the container boundary, which means you see syscalls and stdout but not the agent's intent. ClawLess pairs its AuditLog with a PolicyEngine that the README describes as enforced at the container level, so the same system that records the event also decides whether it was allowed. That coupling is the part worth evaluating against whatever you use today.

Licence, maintenance and what an upgrade costs

ClawLess is MIT-licensed, per the LICENSE file and the badge in the README. MIT is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and permission notice are preserved. That is the general shape of the licence and not legal advice; read LICENSE yourself before shipping.

The published package is clawcontainer, currently at version 1.1.0 in package.json, while the most recent GitHub release listed is v1.0.0 from 2026-03-19. That gap is worth noting when you pin a version: the npm artifact and the tagged release are not the same number.

The repository is not archived, and its last push was on 2026-07-08. That is the maintenance fact to work from. The README does not document a deprecation policy, a support window, or a migration guide between versions, so an upgrade path is something you would have to infer from the commit history and release notes rather than read from a document.

The dependency surface is small, which keeps upgrade cost low: @webcontainer/api, @xterm/xterm, @xterm/addon-fit, jszip and monaco-editor. Each of those is a moving part you inherit. A major bump in @webcontainer/api is the one most likely to force changes in your integration, because it is the runtime everything else sits on.

Editorial conclusion

Adopt ClawLess when the agent must run inside a browser tab with no backend and you want its file, process and network behaviour governed by a YAML policy and recorded in an audit log. Do not adopt it when the agent needs native binaries, long-running background jobs, or direct access to a real machine. Before committing, verify three things: that your target browsers support WebContainers, that the policy keys you need (file access, allowed processes, port bindings, max file size, max processes, max turns, timeout) exist in DOCS.md, and that the GitHub clone and push flow covers your repository's authentication model. The repository's last push was on 2026-07-08, so check the commit history yourself rather than assuming a release cadence.

Frequently asked questions

Official sources

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