
peerd v0.4.0
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.
The first web-native AI agent harness
peerd is the first general-purpose agent runtime built directly on browser primitives: Workers, origins, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn, and WebExtensions. It runs completely inside Chrome and Firefox, with your tabs, signed-in sessions, web apps, and local compute.
While agent platforms are trying to pull the browser into the harness. peerd pulls the harness into the browser.
For actual inference you can choose a supported hosted model provider, a local model using localhost, or check out preliminary support for local WebGPU models (we're keeping an eye on WebNN as well).
No peerd account, hosted browser, or tool-server connection is required. Current builds send no product telemetry to peerd.
Install · peerd.ai · Architecture · Security
Features
- Works in the browser you already use. The agent can read and drive your tabs, web apps, signed-in sessions, and page content.
- Builds reusable site clients. The web actor can learn a site once and use that client again on later tasks.
- Runs code inside browser boundaries. Scripts, sealed JavaScript Notebooks, compiled WASI tools, browser Apps, and Linux WebVMs give the agent local compute without access to your host operating system.
- Delegates to separate actors. Every page and compute environment gets its own keyless actor with tools scoped to that environment.
- Keeps useful context. Sessions, memory, skills, goals, review, and checkpoints live in the extension.
- Uses the model you choose. The live provider inventory is defined in
registry.js, including BYOK cloud adapters and keyless local options. - Connects browsers directly. Preview builds add signed identity, browser-to-browser discovery, dwapps, and agent-to-agent communication over WebRTC; store packages prune it entirely.
Why the browser
Local agents can access your whole computer. Remote agents live in someone else's. The browser is the alternative: local capability behind security boundaries hardened over three decades.
peerd uses those boundaries. Page work goes to separate actors with only the tools for that tab or environment. Credentials, network rules, confirmations, and audit stay with the extension. Its defense-in-depth design assumes unsafe content will eventually get past a filter.
Browser support
peerd supports Chromium and Firefox. 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. Firefox preview builds omit dweb until Firefox has a mesh host.
Apps and WebVMs run on Chrome. Apps have no ambient network access. Remote resources, fetches, WebRTC, forms, and external document navigation are blocked. External HTTP and HTTPS links require user confirmation.
Concrete browser capability gaps, their upstream issues, and the tests required
to remove each guard are tracked in
docs/BROWSER-COMPATIBILITY.md.
The code is the source of truth for current behavior. Start with
CLAUDE.md, then read the relevant module under extension/.
Security model
peerd uses browser isolation, narrow tool exposure, service-worker policy gates, and explicit egress controls. The main agent delegates environment work to keyless actors. On Chrome and Firefox, non-orchestrator agent loops run in separate dedicated worker heaps. If the browser cannot prove that boundary, the actor request does not run and performs no work on its target.
Network behavior depends on the operation. Model calls, web reads, runtime asset
loads, sandbox traffic, and preview dweb traffic use different scoped paths and
policies. See SECURITY.md and the
threat model for the current boundaries and
known limitations.
Install
Chrome from source
- Clone the repository.
- Open
chrome://extensions. - Enable Developer mode.
- Choose Load unpacked and select the
extension/directory.
Reload the extension from chrome://extensions after source changes.
Firefox from source
Firefox needs a Firefox-specific package. Do not load the checked-in Chrome
development manifest. Use a Firefox version at or above the minimum declared in
the channel patch under manifests/. That floor tracks the document-bound
scripting support used by browser tools.
bun run package -- --channel=preview --browser=firefox --no-sign
Open about:debugging#/runtime/this-firefox, choose Load Temporary Add-on,
and select artifacts/peerd-preview-firefox.xpi. Temporary add-ons must be
loaded again after Firefox restarts. Browser and channel transforms are defined
by the packaging scripts.
Release packages
See GitHub Releases for current artifacts. Store and preview builds differ. Store builds omit the dweb. Preview builds include it and may enable additional automation features. The packaging code is the authority for each browser and channel.