Back to updates
New releaseAug 2, 2026

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.

Share


peerd

CI types: ts-check coverage Functional Tests In-Browser Chrome In-Browser Gecko E2E side panel Red Team App source: no development build and unbundled Vendored code Actions pinned License: Apache 2.0 Manifest V3 Security policy

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

  1. Clone the repository.
  2. Open chrome://extensions.
  3. Enable Developer mode.
  4. 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.

First run

Categories