The `nativeMessaging` permission explained: what browser extensions can really do outside your browser

Most browser extension permissions are contained — they reach into your tabs, your cookies, your browsing history. The native messaging permission (nativeMessaging in the manifest) does something different. It reaches outside the browser entirely.

A recent controversy over Claude Desktop made this concrete. According to The Register and Malwarebytes, Anthropic's desktop app silently deposits a Native Messaging host manifest into the profile folders of seven Chromium-based browsers — Chrome, Edge, Brave, Arc, Vivaldi, Opera, and Chromium — including browsers you haven't even installed yet. No prompt, no consent dialog, no opt-in. The manifest just appears.

That manifest pre-authorizes extension IDs to communicate with a native binary that lives outside your browser's sandbox, running with your full user-level OS permissions. This isn't hypothetical. It's a working deployment that shows exactly what nativeMessaging makes possible — and why it's worth understanding before you install anything that requests it.

What the browser sandbox actually does

Before unpacking native messaging, it helps to understand what the browser sandbox protects you from.

Every extension runs inside a constrained environment. Even aggressive permissions like <all_urls> or scripting keep everything within the browser's controlled process space. An extension with scripting can inject JavaScript into your Gmail tab, but it can't write a file to your desktop or launch another application. That wall between browser and operating system is the sandbox.

Native messaging is Chrome's official escape hatch through that wall.

What the native messaging permission actually allows

The nativeMessaging permission enables an extension to open a bidirectional pipe to a registered native application — a regular program installed on your computer, running outside Chrome's sandbox with your user account's full permissions.

Two things must be in place for this to work. First, a native host manifest: a JSON file registered in a specific OS directory that declares which extension IDs are allowed to connect and which local binary they connect to. Second, a native host binary: the actual program that receives messages from the extension and acts on them.

When the extension calls chrome.runtime.connectNative('com.example.myapp'), Chrome looks up the manifest, checks the calling extension's ID against the allowlist, and opens the pipe if the IDs match. What happens on the other side — in the native binary — is entirely up to whoever wrote that binary. The binary runs as your user account. It can read files, write to disk, make network connections, spawn child processes, or do anything else your OS user is allowed to do.

That's what makes this permission categorically different from most others. The tabs permission can see your open URLs; the cookies permission can read your session tokens. nativeMessaging can hand control to a program that runs at the same privilege level as everything else on your machine.

What the Claude Desktop situation shows

Privacy researcher Alexander Hanff published his analysis on April 20, 2026. As The Register reported, Claude Desktop creates com.anthropic.claude_browser_extension.json in the system profile directories of at least seven Chromium-based browsers — even ones not yet installed on the device. The manifest pre-authorizes three Chrome extension IDs and maps them to a local native host binary that operates at user privilege level.

Once paired with the Claude for Chrome extension, The Register reported, the bridge enables "authenticated session access and can read web pages, fill out forms, and capture the screen."

Two details make this notable beyond the normal case of an app installing a native host:

First, the manifest recreates itself every time Claude Desktop launches. Manual deletion doesn't help — the next time you open the app, it's back. Second, the manifest is placed into profile directories for browsers that aren't installed. Arc, Vivaldi, and Opera profile folders get pre-configured for a connection that doesn't yet exist, in case you install one of those browsers later.

Hanff argued this constitutes a violation of Article 5(3) of the EU ePrivacy Directive — the same "cookie law" that requires clear informed consent before storing anything on a user's device. Anthropic has not publicly responded to these findings as of publication.

Security consultant Noah Kenney, also quoted in The Register, described the installation as "a pre-positioned integration layer" rather than malware, but acknowledged "it creates significant regulatory risk in European markets."

The prompt injection angle

There's a practical risk worth spelling out here, especially if you use AI browser extensions.

Anthropic's own published documentation, cited in The Register's coverage, puts the prompt injection success rate for the Claude for Chrome extension at 23.6% without mitigations, and 11.2% with current mitigations. Prompt injection is when a malicious website embeds instructions into its content that trick an AI assistant into taking unintended actions — visiting a page in an attacker-controlled context is sometimes enough.

In a normal browser extension scenario, a successful prompt injection stays inside the browser. The extension might do something you didn't authorize, but the damage is sandboxed.

With a native messaging bridge in place, a successful injection can cross that boundary. The injected command travels down the pipe to the native binary, which acts on it at OS level. What would otherwise be a contained browser incident becomes a potential endpoint compromise. Whether you trust the specific app involved or not, understanding this attack surface matters.

When nativeMessaging is fine — and when it's worth scrutinizing

Not every extension using nativeMessaging is a concern. There are completely legitimate use cases.

Password managers like 1Password and Bitwarden use native messaging to communicate with their desktop apps, which store the encrypted vault. Keeping the vault in the native binary rather than the extension is actually a security improvement — the extension itself never holds your raw credentials. Developer tools use it to save scripts or sync settings across sessions. Enterprise-managed extensions use it to report security telemetry to endpoint tools.

The pattern to watch for isn't "this extension uses native messaging" — it's how the native host ended up on your machine and what it's authorized to do. Concerning signals:

• A desktop app installed a native host manifest without a visible consent step during setup
• The manifest pre-authorizes extension IDs you didn't specifically choose to install
• The native binary has broad system access unrelated to a specific function you actively enabled
• The manifest recreates itself automatically, preventing manual cleanup

How to check what's on your machine

Open chrome://extensions in Chrome, enable Developer Mode (toggle in the top-right), and click "Details" on any extension to see its full permission list. nativeMessaging appears explicitly if the extension declares it.

To check what native host manifests are actually registered on your system, look in these locations:

macOS:

• /Library/Google/Chrome/NativeMessagingHosts/ (system-wide)
• ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/ (current user)

Linux:

• /etc/opt/chrome/native-messaging-hosts/
• ~/.config/google-chrome/NativeMessagingHosts/

Windows:

• Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\

Any .json file in those locations is a pre-authorized bridge. Open it in a text editor — the allowed_origins field lists the extension IDs that can connect, and path tells you which binary they connect to. If you find manifests from apps you don't recognize or didn't consciously set up for browser integration, that's worth investigating.

To see which of your installed extensions request nativeMessaging and how they're rated on security and privacy, check your extensions on Extenshi.

Why this matters beyond Claude

The Claude Desktop case is one high-profile example of a broader architectural pattern that will only become more common.

AI desktop assistants compete on depth of browser integration. The more seamlessly they can read what you're doing in the browser, the better their UX story. Native messaging is the mechanism that makes deep integration possible without requiring a browser extension to hold dangerous permissions on its own. So there's real pressure for every AI desktop app — not just Claude — to pre-position bridges like this.

If you have a desktop app for an AI tool, a productivity suite, or any product that claims "deep browser integration," it's worth checking whether a native host manifest has been quietly placed on your machine. The nativeMessaging permission is legitimate technology. The question, as always, is whether you knew you were opting into it.

Check which of your extensions request nativeMessaging →

---

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].