peerd: a browser extension that runs an agent loop inside Chrome and Firefox
The first AI agent harness native to the browser. A browser extension that runs a full agent loop where you already work: it drives your tabs, spins up sandboxed compute (JS notebooks, WASM Linux VMs, client-side apps), and shares what it builds peer-to-peer. BYOK, no backend, no telemetry.
At a glance
- What is it?
- peerd is an Apache-2.0 Manifest V3 extension that runs a general-purpose agent runtime on browser primitives, delegating page and compute work to keyless actors and connecting to models with your own key. The design is coherent and unusually explicit about its security boundaries; the install path is still source-only and Firefox loses several capabilities.
- Who is it for?
- Adopt peerd if you want an agent that operates your existing signed-in tabs and you are willing to load an unpacked extension from source and read the security docs before granting it page access. Do not adopt it if you need a packaged store install, a supported Firefox feature set, or a stable API surface: the releases are tagged peerd-preview and the README tells you the code, not the docs, is the source of truth for current behavior.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem peerd picks, and the users it assumes
Most agent runtimes make you choose a location. A local agent gets the whole machine and the whole filesystem. A remote agent gets a container somewhere else and a browser it does not own. peerd takes a third position: the harness itself lives in the browser you already use, so the tabs, the signed-in sessions and the web apps are the working surface rather than something the agent has to be handed. The README frames this as the inversion, "while agent platforms are trying to pull the browser into the harness, peerd pulls the harness into the browser."
That framing sets the audience. This is for engineers who already live in a browser with a dozen authenticated tabs open and want an agent to act there without exporting cookies, session tokens or page state to a server they do not control. It is also for people who want local compute without giving an agent host OS access: the README lists JavaScript notebooks, compiled WASI tools, browser Apps and Linux WebVMs as the compute surfaces, all inside browser boundaries.
The cost of that position is real. Everything peerd can do is bounded by what a Manifest V3 extension is allowed to do, and the README is upfront that the bound is enforced rather than worked around.
Keyless actors and the delegation boundary
The central mechanism in the README is delegation. The main agent does not hold tools for every page. Instead, "every page and compute environment gets its own keyless actor with tools scoped to that environment." Credentials, network rules, confirmations and audit stay with the extension. A page actor is therefore not a general agent with a broad toolbelt; it is a narrow worker holding only the tools for the tab or environment it was created for.
On Chrome and Firefox, non-orchestrator agent loops run in separate dedicated worker heaps. The README states the failure mode explicitly: if the browser cannot prove that boundary, the actor request does not run and performs no work on its target. That is a fail-closed design, and it is the strongest claim in the material. It also means a browser that cannot provide the isolation does not degrade into a less safe mode, it stops.
Network access is not one policy but several. Model calls, web reads, runtime asset loads, sandbox traffic and preview dweb traffic each use "different scoped paths and policies" according to the README. The threat model and SECURITY.md are cited as the current statement of where those boundaries sit and what is known to be weak. If you are evaluating peerd for anything sensitive, those two documents are the review, not the README.
The README also says peerd builds reusable site clients: the web actor can learn a site once and reuse that client on later tasks. How that learned client is stored and invalidated is not described in the material I have, so treat persistence and staleness as something to check in the code under extension/.
Getting it running from source, on each browser
There is no store listing described in the README. Installation is from source. For Chrome: clone the repository, open chrome://extensions, enable Developer mode, choose Load unpacked and select the extension/ directory. After source changes you reload the extension from chrome://extensions.
Firefox is stricter and the README warns against the obvious shortcut: do not load the checked-in Chrome development manifest. You need a Firefox-specific package, built with the documented command:
bun run package -- --channel=preview --browser=firefox --no-sign
Then open about:debugging#/runtime/this-firefox, choose Load Temporary Add-on and select artifacts/peerd-preview-firefox.xpi. Note the word temporary. The README's Firefox instructions end mid-sentence in the material I have, so I cannot confirm what it says about permanent installation or signing. The --no-sign flag in the quoted command suggests signing is a separate step, but the material does not describe it.
The README also states a version floor: use a Firefox version at or above the minimum declared in the channel patch under manifests/, because that floor tracks the document-bound scripting support the browser tools rely on. That is a concrete prerequisite you can check before building anything.
Inference is bring-your-own-key. The live provider inventory is defined in extension/peerd-provider/registry.js, covering BYOK cloud adapters and keyless local options, with preliminary WebGPU model support and WebNN noted as something being watched. No peerd account, hosted browser or tool-server connection is required, and current builds send no product telemetry to peerd.
Where peerd is the wrong tool
Firefox is the clearest limitation, and it is documented rather than hidden. Firefox runs actors in dedicated workers and uses visible notebooks for JavaScript compute. Features that need Chrome's offscreen document host are removed from Firefox controls and model tools before use, and Firefox preview builds omit dweb until Firefox has a mesh host. Apps and WebVMs run on Chrome only. If your work depends on browser Apps or a Linux WebVM, Firefox is not a partial substitute, it is a different product.
The Apps sandbox is deliberately restrictive. Apps have no ambient network access, and remote resources, fetches, WebRTC, forms and external document navigation are blocked. External HTTP and HTTPS links require user confirmation. That is a sensible boundary for agent-generated code, but it means an app that needs to call an API will not work as written.
Preview builds add signed identity, browser-to-browser discovery, dwapps and agent-to-agent communication over WebRTC, and store packages prune that entirely. So the peer-to-peer sharing in the description is a preview-channel feature with a different trust surface from the store build, not a uniform property of the project.
The material also gives no stability commitment. Releases are tagged peerd-preview-v0.7.x, the README says the code is the source of truth for current behavior, and it directs readers to CLAUDE.md and the relevant module under extension/ rather than to a stable API. Anyone expecting a frozen extension API should look elsewhere.
How this differs from driving a headless browser from a server
The obvious alternative is a server-side agent that controls a browser through a driver protocol: Playwright or Puppeteer launching Chromium in a container, with the agent loop and the model credentials on the server. The mechanical difference is where the session lives. In that model the browser is a fresh, unauthenticated instance the agent must log into, and every cookie it uses passes through infrastructure you operate. In peerd the session is the one you already have, and the README's claim is that page work goes to separate actors with only the tools for that tab while credentials, network rules, confirmations and audit stay with the extension.
That difference cuts both ways. A server-side driver gives you reproducible environments, scheduled runs and no dependency on a user's browser being open, none of which peerd's model offers. peerd gives you the real signed-in web and a compute sandbox that is bounded by browser isolation rather than by a container you configured. If your task is a nightly scrape of public pages, the server-side driver is the better fit. If your task is acting inside an authenticated workflow that only exists in your browser, peerd is addressing a problem the server-side driver handles badly.
The second alternative is a local desktop agent with filesystem and shell access. It can do more, and the README's own argument is that this is exactly the trade it refuses: local capability behind security boundaries rather than local capability behind nothing.
Maintenance, packaging and licence
The repository is active, not archived, with a last push in September 2026 and preview releases in August 2026. The project ships an unusual amount of packaging machinery for a browser extension: a package-and-release CI workflow, TypeScript check coverage, functional tests, separate in-browser Chrome and Gecko runtime test runners, an end-to-end side panel verification script, a red team results document, a vendored-code lockfile with an integrity badge, and a check that pins GitHub Actions. There is also a badge asserting that the app source is unbundled with no development build, pointing at CONTRIBUTING.md.
For an adopter, that machinery is the upgrade story. Reloading an unpacked extension is manual on Chrome, and Firefox temporary add-ons do not survive a restart in the way a signed add-on does, so every update is a rebuild plus a reload rather than an automatic store update. The Firefox path requires re-running the packaging command and re-loading the artifact. Budget for that, and for reading the browser compatibility document when a guard is removed.
Licensing is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices, but this is not legal advice and you should read LICENSE and any third-party notices yourself, particularly given the vendored code and the vendor.lock.json integrity check. The security policy lives in SECURITY.md, and the threat model in docs/security/THREAT-MODEL.md is where the project states its known limitations.
Editorial conclusion
Adopt peerd if you want an agent that operates your existing signed-in tabs and you are willing to load an unpacked extension from source and read the security docs before granting it page access. Do not adopt it if you need a packaged store install, a supported Firefox feature set, or a stable API surface: the releases are tagged peerd-preview and the README tells you the code, not the docs, is the source of truth for current behavior. Verify three things first: that your chosen provider appears in extension/peerd-provider/registry.js, that your browser meets the floor declared in the channel patch under manifests/, and that the guard list in docs/BROWSER-COMPATIBILITY.md does not cover a capability you depend on.
Community notes