Peerd: First Browser-Native AI Agent Extension

Trending GitHub project peerd runs AI agent loops in Chrome/Firefox, driving tabs and sandboxed compute (JS, WASM) peer-to-peer with no backend or telemetry.

Peerd: First Browser-Native AI Agent Extension

Peerd Overview

NotASithLord released

peerdNotASithLord
View on GitHub โ†’
on GitHub, where it appeared in trending repositories. The project provides a Chrome and Firefox extension that executes an AI agent loop entirely inside the browser. It controls open tabs, launches sandboxed execution environments such as JavaScript notebooks and WebAssembly Linux VMs, and supports peer-to-peer sharing of artifacts over WebRTC. The extension requires users to supply their own model API keys and contains no server-side component or telemetry collection.

Core Features

The extension exposes three primary capabilities. First, it reads and manipulates the DOM of existing tabs through verified action sequences that re-check page state after each step. Second, it provisions isolated compute contexts: V8 isolates for JavaScript notebooks, compiled WASM binaries for Linux-like environments, and opaque-origin iframes for client-side applications. Third, the preview channel implements a WebRTC signaling layer that lets agents exchange data directly without an intermediary relay.

These features run under the browser's existing security boundaries. The extension delegates sandboxing to V8 isolates and WebCrypto for key storage, while WebAuthn passkeys control vault access. A disposable runner process handles page interaction; it holds no credentials and forwards only fenced output back to the main agent.

Implementation Approach

The repository organizes code into distinct packages. The extension directory contains manifest files and content scripts. The web-prototype directory holds a standalone demonstration of the agent loop. A signaling-node package manages WebRTC peer discovery for the P2P channel. Build scripts produce separate artifacts for Chrome and Firefox using the same TypeScript sources.

Model interaction follows a bring-your-own-key pattern. Users configure endpoints and credentials locally; the extension forwards requests directly from the browser. No intermediate proxy exists in the data path. The architecture document lists explicit constraints on what the agent may access, including restrictions on raw page content and network capabilities for runner contexts.

Practical Considerations

Current status remains 0.x experimental beta. The initial feature set is integrated, yet the project carries the usual risks of early browser extensions that interact with live pages and external model endpoints. Performance depends on the host browser's resource limits and the latency of the chosen model provider.

Developers evaluating the extension should review the SECURITY.md and ARCHITECTURE.md files before installation. The absence of a backend reduces certain attack surfaces but shifts responsibility for key management and update verification entirely to the user. Extension updates still flow through the browser store, which retains its standard review process.

Does Peerd require a specific model provider? No. The extension accepts any OpenAI-compatible endpoint once the user supplies the corresponding API key in the local settings.

Can the agent access files outside the browser? No. All compute occurs inside sandboxed browser contexts or WASM VMs; the extension never requests native file-system access beyond what standard web APIs allow.

Is peer-to-peer sharing enabled by default? No. The WebRTC channel is restricted to the preview release and must be explicitly activated in the extension options.

---

๐Ÿ“– Related articles

Need a consultation?

I help companies and startups build software, automate workflows, and integrate AI. Let's talk.

Get in touch
โ† Back to blog