Show HN: peerd – AI agent harness that runs entirely in your browser
github.comHey HN. http://peerd.ai is an AI agent harness that lives entirely in your browser as a web extension. You don’t have to install a separate “AI browser”. You don’t have to bolt on or run some external process or manage a clunky mcp integration. It’s just a fully contained web extension, written in no build vanilla JS with minimal non-browser dependencies, using your own provider keys, and Apache 2.
This isn’t just a fun hack. While it has largely been a solo side project, I genuinely believe the browser and the web could be the most natural platform for AI agents to operate safely, autonomously, and most importantly without A2A middlemen (more on that in a sec). To demonstrate that point peerd doesn’t just drive browser automation. It spins up isolated sandboxes using tabs and worker instances to support various real workload types. Those include headless JS computational work, visual JS notebooks, personal client side apps, and real Linux VMs on top of wasm with full http networking.
The industry discourse over the last several months has been dominated by “which substrate is the best for ai agent sandboxes” with many competing answers focused on different models and use cases. Cloudflare is one of the most prominent examples, positioning its v8 isolate based workers as the best in class solution thanks to faster than container startup times and strong isolation guarantees. The v8 isolate is of course the product of chromium, which runs on billions of browsers around the world for free. The browser as a whole is perhaps the most battle tested sandbox system in the entire software industry. It’s been built on 3 decades of learning from hostile content, hostile code, and hostile users. Native and cloud agents are necessarily rebuilding all or most of this posture from scratch. peerd doesn’t. It leverages everything the browser has to offer and pushes it to its functional limits, while inheriting its security baseline and isolation from the host system.
Robust sandboxing isn’t the only thing the browser offers and peerd uses. It comes with extremely powerful and underrated primitives, from webCrypto, webRTC, webAuthn, webGPU, and ~soon WebNN. Direct web access, with your real live sessions, and api calls with fetch present an alternative model to MCP integrations. The agent can write and spawn web apps right there in a tab, no hosted service necessary. Then there’s the A2A piece: peerd already has a rudimentary p2p (peerd-to-peerd?) network in place using webRTC. Today you can connect with peers on the network, add them as contacts, and share signed apps you’ve created. I’m working on extending these apps to be able to leverage the same p2p network to support decentralized web apps (dwapps), as well as facilitate true p2p A2A with no platform or middlemen.
Given this is an early part time project, this is an extremely experimental build and in a v0.x preview state. I’ve taken care to attempt to address the lethal trifecta: the main agent loops/sessions never ingest untrusted DOM code or possess low level navigation tools. It delegates those tasks to dedicated web runners with no wider tooling or secrets access that return summarized results. Both the DOM and the summarized results are bracketed as untrusted, meaning two stacked prompt injection escapes are needed. All egress goes through a central module that has a customizable deny list, and only models calls to designated allowed endpoints are possible. See more in the docs, site, and the code itself. Ultimately, use at your own risk.
Today anthropic, open router, local ollama, and even an experimental WebGPU instance of Gemma are supported.
Honest limitations: Chrome store and AMO are still pending until it can get more eyeballs and live usage. Just loading unpacked from GitHub is the easiest way to go, and as a bonus makes it easy to audit thanks to no build. Linux on wasm depends on the Cheerpx engine, which is not open source and has restrictions for commercial use. That may be a good reason to reassess it compared to alternatives, but it’s also the most performant and looks closest to implementing 64bit support.
Poke around, use it, critique it, and have fun.
That's cool. Sounds very impressive. What's the point of all this security though?
You don't want it to access your files, just give it its own Linux user. You don't even need a container.
Better yet, you can give it root on a $3 VPS (or $30 Thinkpad) and get a sysadmin for free :)
Although, Cheerpx... that seems to imply your agent can play Java and Flash games. Alright, you might be on to something!
I hope so! There's different approaches for different use cases, for sure. This seemed like a genuinely new one worth exploring and seeing where it goes. I think the benefits are that the agent "lives" where most people already work and live their online lives. Has direct web access, and all the other browser primitives I've tried to demo. But yeah, wasm especially opens up literally any kind of application as well. The guys at CheerpX have made a great engine and 64-bit is going to be a big unlock.
> just give it its own Linux user
it's never "just" ...
(for example: how do you manage this across multiple isolated sessions?)
opening a browser is much easier
... and the entry barrier for non-linux people at your company is much much lower
... and the compliance barrier for companies is much much lower (how do you ensure that everyone creates the users correctly?)
Author here. Some other technical tidbits:
- Fully typed checked with JSdoc, and Bun/TS for testing.
- stdlib-js is injected into every js runner and notebook for better math capabilities than vanilla js, and also charts etc.
- App dev tasks utilize mithril for making SPAs, a very small no-dependency framework that is very fit to purpose for the client side nature of peerd apps.
- Currently on main, tabs are global objects each chat session can freely mutate, which is not great. The new in progress model has one "resident" agent own every tab. Only they have the exposed capability to mutate it, and everything between agents/sessions is message based. This has some cool properties: further isolation between contexts, mirroring the web runner subagent. Explicit ownership and scope is cleaner and better for parallel ops. Context and system prompts can be reduced and focused to the specific context the session is exposed to. The orchestrator doesn’t have any low level tab interactions available to it. The tab residents have only the tab interaction tools relevant to it, and the instructions specific to the tab type (js notebook, linux vm, app dev, etc). Over time model usage can be tuned and optimized for each specific context etc.
JSdoc? Not typescript? What is this, 2010?
It's vanilla JS with no unnecessary build step. Runs in the browser as is, and easy to audit.
If the web runners return summarized results and those are still treated as untrusted, what's stopping a summary itself from carrying the injection up to the main loop?
It's defense in depth, definitely not a silver bullet. The web runner has no access to wider capabilities outside of that page. So the only path for a prompt injection to do anything is to try and get itself included in the summary, and get the main loop to act on an instruction in that summary. That means getting pass two sets of <untrusted> tags and explicit instructions to treat everything inside as information, not instruction. Then the egress checkpoint and allow/deny whitelists are the final guards regardless of what the main loop decides to do. Trying to harden wherever I can if you have any recs.
> The name is always lowercase: peerd.
Gotta love it when agent instructions get blurted out in user-facing documentation
It's a project convention for human contributors as well. Agree it can probably be relocated though.
Moved
> The bet is structural
Why has AI writing become so insufferable?
The project would be a lot more credible if the feature list wasn't so comically extensive and verbose [1]. Slop overload.
[1] https://github.com/NotASithLord/peerd/blob/main/FEATURES.md
Scrubbed. Taking a fresh pass through.
I'm going to do a simonw here and coin "Markdown hoarding" for the Claudeism of producing reams of hyper-dense prose and compounding it with every commit that touches docs. The documentation gets more and more bloated.
The default Claude voice is breathless, jargon-heavy showboating:
This isn't a critique of the author, more of Opus, but I'd be curious what effect https://github.com/blader/humanizer/blob/main/SKILL.md might have.
Agree on markdown bloat/hoarding. Appreciate the feedback, already doing a pass based on other feedback and trimming fat.