Native messaging

#How native messaging works

The host manifest names the host program and lists which extensions may connect to it. When an extension connects, the browser starts the host as a separate process. Each message is JSON with a length header, and the messages flow in both directions. When the extension disconnects, the host ends.

The Chrome documentation covers the manifest fields and the message format in detail.

#Why it matters for AI agents

Native messaging is the standard way to link a browser extension to a local program, without a network port. Compared with a local HTTP server, the browser controls which extension can connect, and the host runs only when it is needed.

This makes it a practical bridge for agent tools. A browser extension can reach a local process that talks to an AI app, and the traffic never leaves the computer.

#Wield and native messaging

Wield's bridge uses Chrome native messaging to connect wield-mcp and the Wield extension. The chain is: the AI app talks to wield-mcp over stdio, wield-mcp talks to the bridge, and the bridge talks to the extension. The bridge is local only. It uses a socket in ~/.wield on macOS and Linux, or a per-user named pipe on Windows. There is no network port.

Wield runs in Chrome, Edge, Brave, Arc, Vivaldi, Opera and Chromium.

#Related terms

• Stdio transport
• Manifest V3
• MCP server
• Local-first software

#FAQ

#Why use native messaging instead of localhost HTTP?

A localhost HTTP server listens on a port that any local program can reach. Native messaging has no port. The browser starts the host, and only the extensions named in the host manifest can connect to it.

#Does native messaging work in Edge and Brave?

Native messaging is part of the Chromium extension platform, and Wield runs in Edge and Brave. Wield's bridge uses native messaging in each of the browsers it supports.