A browser extension is split between the page and the browser

A website can only change itself. Its JavaScript can't read another tab, block the ads on a different site or see which address you have open. Browsers keep it that way on purpose: otherwise any page could spy on every other.

Yet an ad blocker strips every site you visit, a password manager fills forms on all of them, and an AI agent can click through a page you're building. These are extensions, and they are the one sanctioned way past that wall. So what is an extension, and how does it reach a page that isn't its own?

An extension is HTML, CSS and JavaScript in a folder, the same material as any site. Chrome gives it an address of its own, chrome-extension:// followed by a long id, so its files load like a tiny private website.

What makes it more than a website is one required file, its manifest⁹⁵: manifest.json. It names the extension, lists the permissions it wants (tabs, storage) and the sites it may reach (https://*.github.com/*), and says which of its files run where. The warning you see at install time, "Read and change your data on github.com", is that list read back to you. Chrome lets the code do nothing the manifest didn't ask for.

The format in use is Manifest V3. Chrome has switched the older V2 off.

A website asks for nothing and gets its own page. An extension asks for powers in its manifest, and you grant them when you install it.

The powers it asks for live in two different places, so its code is split between them.

The content script⁹⁶ runs inside the web page. Chrome puts it into every page the manifest matches, and it can read and change that page's DOM⁸²: hide an element, add a button, restyle the lot. It does so from an "isolated world": it sees the same elements as the page's own scripts, but neither can see the other's variables, so a hostile page can't tamper with the extension's code. Inside the page it gets only a few of the browser's extension APIs.

The service worker⁹⁷ runs in the browser, outside every page. It has no DOM, but it holds the powerful chrome.* APIs: the tabs, the toolbar icon, storage, screenshots, the rules for blocking requests. Chrome stops it after 30 seconds with nothing to do and starts it again when something happens, so it can't keep anything in a variable; what it must remember goes into chrome.storage.

Around them sit the extension's own pages: the popup under its toolbar icon, which exists only while it is open, and sometimes a side panel that stays.

The content script can touch the page but not the browser. The worker can touch the browser but not the page.

The halves can't call each other's functions, so they talk the way two programs do: one sends a message, as data, and the other listens for it (chrome.runtime.sendMessage and onMessage). If you build for the web, you know this shape already. It is a page calling an API route on its own server: two places, JSON in between.

That gives a rule for reading any extension. Ask of each feature: does it need to see or change the page? That is the content script. Does it need something only the browser controls? That is the worker. If it needs both, a message crosses.

A full-page screenshot shows the rule at its busiest. The worker has the camera: chrome.tabs.captureVisibleTab() returns what is on screen, and nothing a content script can call does that. But the worker doesn't know how tall the page is, or how to scroll it. So the two take turns, one screenful at a time.

A password manager shows why the split is also a safeguard. The content script finds the login form and says so. The worker, which keeps the vault, sends back only the one login for this site, and the content script fills it in. The vault never enters the page.

The content script is the extension's hands in one page. The worker holds the browser's keys. Messages carry the work between them.

An AI agent that works in your browser, such as the Claude extension for Chrome, has the usual pieces: a side panel to talk to it in, a worker that opens tabs and keeps them in a tab group of their own. To use a page as you do, though, the two halves aren't enough.

A content script can click a button by calling button.click(). The page receives a synthetic click, marked isTrusted: false, which a site can tell apart and some ignore. And a content script can't see the page's console errors or its failed requests, which is most of what debugging needs.

So the agent asks for one permission most extensions never do: debugger. It lets an extension use the Chrome DevTools Protocol⁸³, the channel the DevTools panel itself uses: JSON commands such as Input.dispatchMouseEvent and Page.captureScreenshot sent to a tab, and events such as Runtime.consoleAPICalled sent back. A click sent this way goes through Chrome's real input, and the page can't tell it from yours. Chrome shows a bar saying the extension "started debugging this browser" for as long as it is attached.

This is the same channel a browsing agent's harness uses to read a page and act on it (The page reaches the model as text), and the same one testing tools use. What differs between them is who sends the commands, and to whose browser.

With debugger, an extension stops being a page script and a worker, and becomes DevTools that nobody is watching.