After seven straight days of dev, test, dev, test, and review around my HCode project, I am back to the other idea that has been sitting in my head: using WebGPU to build a popular OpenClaw alternative that runs directly in the web browser.
This is Day 4 of HCode, and also the introduction of my new two-week side project called WebClaw.
At the same time, HCode itself is still being tested from a user point of view. My friend is handling simulated attacks, product testing, reviews, and suggestion sharing from an actual user perspective. That gave me room to step aside for a bit and work on this browser-native agent idea properly.
Why I Started WebClaw
I have been following the Clawland ecosystem closely. MicroClaw, PicoClaw, and OpenClaw are all genuinely interesting, and they pushed me to think more seriously about what an agent runtime could look like.
But I had a simple problem.
I am afraid of opening ports and setting up some random always-on gateway on my only laptop just to experiment with agents. I am not rich, bro. I do not have spare Mac Minis sitting around. And I do not need the hardware-side depth of PicoClaw right now. I am just experimenting, learning, and trying to build something practical.
So I started asking a different question:
What if the whole runtime lived inside the web browser?
That is the basic idea behind WebClaw.
How I Want It to Work as a Product
The product-stage flow I am aiming for is very simple:
- Open WebClaw in your laptop browser.
- Log in with your UID.
- Keep that browser session open.
- Open the same URL from your phone.
- Log in with the same UID.
- That is it.
From there, the goal is that you can download files, edit files, and control your local computer through a very restricted local OS agent, while the intelligence layer is powered by your own LLM API keys or your own local Ollama models.
That means the product is intended to support the kinds of things people want from OpenClaw-style workflows, but in a browser-native form factor that is easier to access and easier to experiment with.
Where WebClaw Fits
I do not think of WebClaw as replacing the existing Clawland stack. I think of it as an independent browser-native layer inspired by that direction.
The Core Idea
WebClaw is designed around one thing: making agent workflows feel immediate inside the browser instead of heavy before you even begin.
The browser is not just the UI here. The browser is the actual runtime surface.
That matters because it changes the whole user experience. Instead of asking people to install half a stack before trying anything, the target experience is just: open URL, log in, keep moving.
What Makes It Different
Tab-Based Agent Delegation
One of the most interesting parts of the idea is that browser tabs can become agent containers.
You can name tabs by agent role and task them accordingly. One tab can be your coding agent. Another can be your research agent. Because they can run in separate Web Workers, they can compute in parallel and stay naturally separated.
Claw Mesh
If multiple agents are running across tabs and windows, you need a way to inspect them.
That is where Claw Mesh comes in. The idea is to use BroadcastChannel so browser tabs can discover and communicate with each other without needing a separate coordination server. The panel becomes a place to check which agents are running and what each one is doing.
WebGPU Compute
This is the part that made the whole thing exciting for me.
Instead of treating the web browser like a weak shell, WebClaw treats it like a serious compute environment. WebGPU is the reason that feels possible. If vector math and retrieval can run properly in-browser, then the agent story becomes much more interesting.
That is the route I want to push.
Why I Chose the Browser Runtime
This design is really about security, accessibility, and trust.
With a traditional agent setup, the usual flow is messy: install dependencies, run a daemon, expose a local port, and keep some long-lived process alive on your machine. If you want to use that runtime from your phone, the networking story gets even worse.
That is exactly what I do not want on my only laptop.
In WebClaw, the browser is the runtime surface.
- Files can live in the Origin Private File System (OPFS), which is sandboxed away from the normal host filesystem.
- The local OS bridge can be handled through Chrome Native Messaging instead of a persistent WebSocket gateway.
- That means commands run through a tightly limited bridge instead of a permanently exposed local port.
For me, that is the biggest reason to build it this way.
Why I Think It Is Worth Building
The strongest reason I keep coming back to this project is that it feels like the browser can now do much more than people give it credit for.
If this works well, WebClaw could become a browser-native agent layer where you get:
- immediate access from laptop and phone
- agent separation across tabs
- live visibility through Claw Mesh
- local control through a restricted bridge
- your own model choice through API keys or Ollama
That is a very interesting product surface to me.
WebClaw is basically me asking one question seriously:
How far can we push the web browser before we actually need a traditional local agent runtime?
That is the experiment, and I think it is worth exploring in public.
If you are reading this and you have thoughts on the idea, I would genuinely like to hear them.
The code is here: github.com/Vasanthadithya-mundrathi/webclaw
I have my final midterm tomorrow, so that is all for today. After these exams are done, I will get back to my project work and I am also planning to start contributing more to open-source projects.
Share your thoughts.
See ya.
— Vasanth