The main Cowork architecture page documents this surface at the macOS level.
This page provides the full technical characterization of the signal path, the
pre-installation registration mechanism, and the relationship to
Genesis.Genie — the clean-room reconstruction of the native host binary.
Claude Desktop silently installs a Native Messaging host manifest
(com.anthropic.claude_browser_extension.json) into the configuration
directories of Chromium-based browsers on the host — Chrome, Edge, Brave, Arc,
Vivaldi, Opera, and others — including browsers not yet installed at the time of
registration. No disclosure is made during installation. No consent is requested
at install time or when a browser subsequently finds the pre-registered manifest.
Independent discovery of this surface occurred in January 2026. Public coverage appeared approximately three months later.
The registered native host is chrome-native-host, a Rust binary
(2.1 MB, universal x86_64+arm64 on macOS) that runs outside the browser sandbox
at user privilege. It is the only binary the extension can communicate with via
the native messaging protocol, and its execution is authorized by the pre-registered
manifest without additional prompting.
| Permission | What it grants | Scope |
|---|---|---|
debugger |
Attach Chrome DevTools Protocol to any tab | Full read/write of page state, network traffic, storage. Operates outside the normal extension sandbox. |
<all_urls> |
Content script injection into any page | DOM access, form reads, screen capture. No per-site consent required. |
webRequest on api.anthropic.com |
Intercept all requests to the Anthropic API | Read request bodies before they leave the browser. Browser-layer analog to the Cowork TLS interception, operating before TLS is established. |
chrome.runtime.connectNative() → chrome-native-host — Rust, outside browser sandbox, user privilege
The webRequest listener on api.anthropic.com intercepts
at the browser network layer — before the request is encrypted for transport.
This is structurally different from the CCR proxy (which operates at the container
TLS boundary) and the sdk-daemon proxy (which operates inside the VM at TLS).
The browser extension layer sees plaintext request content before any TLS layer
can intercept the ciphertext. In a complete request path through all three layers,
this is the first point of interception.
Genesis.Genie is a clean-room reconstruction of the chrome-native-host
native host binary, built from behavioral observation of the native messaging protocol
and the capabilities exposed by the binary. It is not a fork or modification of
the original binary.
The reconstruction produced:
Genesis.Genie.Bridge — managed bridge for the native messaging protocolGenesis.Genie.NativeHost — host-side implementation (C#) of the native host capability surfaceGenesis.Genie.Bridge.Tests and Genesis.Genie.NativeHost.Tests — conformance test suitesThe four assemblies reside on the development machine and have not been committed to the public monorepo.
debugger permission in the extension and Genie's CDP access capability
reach the same Chrome DevTools Protocol surface — full tab state, network, storage.
The extension operates from inside the browser's extension sandbox with manifest-declared
permissions. Genie operates from the desktop level, outside the browser entirely.
Two paths to the same capability, from different trust contexts, with different
user visibility.
In the context of a complete API call from a browser session through to the Anthropic API:
| Layer | Position | Sees | TLS? |
|---|---|---|---|
| Browser extension webRequest | Before TLS | Plaintext request as constructed by the browser | No — pre-TLS |
| CCR / Egress Gateway | Container TLS boundary | Re-encrypted ciphertext from container outbound path | Yes — MITM at TLS |
| sdk-daemon proxy | Inside Cowork VM | Re-encrypted ciphertext from VM processes | Yes — MITM at TLS |