Back to articles

AI agent extension permissions explained: what 'read all your data on all websites' really allows

An AI agent extension like OpenAI's Codex asks to 'read all data on all websites.' Here's what it really allows, why agents need it, and how to check yours.

Maxim Kosterin
8 min read

OpenAI shipped a Chrome extension for its Codex coding agent on May 7, 2026. According to OpenAI's own developer documentation, the install dialog asks for two things that should make you pause: "Read and change all your data on all websites" and "Read and change your browsing history on all your signed-in devices." Four million people install per week have already clicked through.

I'm not picking on Codex specifically. The permissions are doing exactly what an AI agent extension like this needs to do — log into Salesforce on your behalf, poke at a Gmail thread, read DevTools output, hop between authenticated tabs. The interesting question is what those permission strings actually grant in the extension model, and how a regular user is supposed to reason about that. So let's go through it.

What "read and change all your data on all websites" really means

In the Chrome extension manifest, this string is the friendly-name for <all_urls> host permissions plus the scripting or content-scripts entry point. The combination gives an extension three things at once:

  1. Read access to the DOM of every page you visit. Form fields, text content, hidden inputs, draft messages, two-factor codes that briefly appear on screen — all of it is readable from a content script.
  2. Write access to the DOM. The extension can inject, modify, or delete any element on the page. It can autofill a form, click a button, change the displayed text of a transaction, or replace your input with something else before it submits.
  3. Network observation and modification via declarativeNetRequest (or webRequest for enterprise builds). With the right combination, the extension can block, redirect, or alter HTTP requests your browser makes.

The phrase "your data" in the install dialog is genuinely accurate. From the browser's point of view, "your data" includes anything visible inside a tab. That covers logged-in sessions, banking dashboards, internal company tools, AI chat transcripts, healthcare portals, and the contents of every Google Doc you have open.

I covered the technical mechanics in more detail in my earlier piece on the host permissions field. The short version: there is no per-page consent step after install. Once you've granted <all_urls>, you've granted it everywhere, forever, until you uninstall.

What the browsing-history permission adds

This is the second permission line in the Codex install dialog. In manifest terms, this is the history permission. Most people assume it means "the extension can see what's in your address bar," and that's a fair plain-English reading. The technical reality is broader.

The history permission gives an extension access to chrome.history.search, which returns every URL you've visited in the time window the extension asks for, along with the timestamp and visit count. It can also delete history entries. On a synced Google account, the history is pulled from Chrome Sync, which is why the dialog explicitly says "on all your signed-in devices" — the extension can see what you browsed on your laptop, your phone, and any other Chrome instance signed into the same account.

Combine <all_urls> content scripts with history access, and an extension knows where you've been and what you did on each of those pages. That is, by design, almost everything a browser can know about you.

What an AI agent extension does with this

OpenAI's documentation is more honest than most about why these permissions are needed. Per the Codex developer docs, the extension is built to "test web apps, gather context across tabs, use web DevTools efficiently in parallel." For an agent that automates browser tasks, those are real requirements. You can't have an assistant that fills in a Salesforce form on your behalf if it can't read or write fields on salesforce.com.

Codex also adds a permission you don't see in most extensions: "Access the page debugger." That's the debugger permission, which gives the extension Chrome DevTools Protocol access — the same low-level interface used by Puppeteer and Playwright. With it, an extension can simulate clicks, read network traffic, run arbitrary JavaScript in the page's main world (bypassing the content-script isolation that normally limits what extensions can touch), and step through code line by line.

To OpenAI's credit, the Codex extension does add a runtime confirmation step: when the agent tries to access a new website for the first time, it shows a per-domain approval dialog, as documented in the developer docs. That's a real mitigation — it converts an always-on broad permission into a per-domain consent flow. It's also why the extension isn't available in the EU or UK yet, where the regulatory bar around exactly this kind of consent UX is harder to clear.

The pattern matters because other AI agent extensions exist that don't have the runtime confirmation step. The Perplexity Comet agentic browser had a calendar-invite prompt-injection vulnerability that let attackers piggyback on the agent's authority to take actions on the user's behalf. The architecture is the same; the safety rails are not.

Risk assessment: when this permission tier is okay, and when it isn't

The honest answer is that "read all data on all websites" can be legitimate. A password manager needs it to fill forms. An ad blocker needs it to rewrite page content. A real AI agent needs it to act on your behalf.

The permission itself is not evidence of malice.

What separates a safe install from a risky one is the set of constraints around the permission, not the permission itself. Here's the checklist I run through:

  • Is the publisher named, accountable, and recoverable? Codex is published by OpenAI, has a verified developer record, and a privacy policy you can hold them to. An extension shipped by "DevExt Solutions LLC" with no website and a generic Gmail support address has none of that.
  • Is the data flow documented? OpenAI tells you that page contents enter their servers only when the user submits them as part of a conversation. That's a falsifiable claim — researchers can verify it with a network trace. Many extensions say nothing useful at all on this point.
  • Is there a runtime consent layer? The per-domain approval dialog Codex adds is rare. Most <all_urls> extensions just go silent once installed.
  • Is the code open or auditable? OpenAI's extension is not open source, but it's a high-profile target — independent researchers will dig into it. A no-name extension with the same permissions has nobody watching.
  • Does the permission match the stated job? A PDF viewer asking for <all_urls> plus history is a mismatch worth questioning. An agentic coding assistant asking for the same set is consistent with its function.

The other piece worth naming: even a perfectly behaved AI agent extension is a concentrated trust target. Researchers at LayerX disclosed a separate vulnerability — I broke it down in my earlier piece on the ClaudeBleed cross-extension hijack — where any zero-permission extension on the same browser could ride on Claude's authority. When you install a broad-permission AI extension, you're not just trusting that vendor. You're trusting that no other extension in your browser will figure out a way to talk to it.

How to check what you've actually granted

Three quick checks I do whenever I install something that looks remotely agentic:

  1. Open chrome://extensions and click "Details" on the extension. Scroll to "Site access." If it says "On all sites," that's the <all_urls> host permission in plain English.
  2. Open the same Details page and scroll to "Permissions." Read the list. history, cookies, debugger, nativeMessaging, clipboardRead, webRequest — each one is a different category of access. The full meaning of each is documented at the Chrome extensions API reference.
  3. For broad-permission extensions, switch site access to "On click" if the extension supports it. Chrome lets you downgrade a granted <all_urls> to per-click activation after install. The extension will only run when you explicitly click its toolbar icon. That single change turns a permanent broad permission into a per-use one for most use cases.

If you don't want to walk through every installed extension by hand, scan your extensions with Extenshi — the scanner pulls each extension's manifest, flags <all_urls>, history, debugger, nativeMessaging, and other high-trust permissions, and tells you which ones in your set are concentrated risks worth re-evaluating. You can also browse the catalog for AI agent extensions and read their permission profiles before installing.

The agentic-browser pattern isn't going away. Engadget noted that Codex grew 8× in users between January and May 2026, and Neowin reported the macOS and Windows rollout is the first of several planned platform expansions. Anthropic, Google, and several smaller companies are shipping comparable agents. The permission ask is going to become a regular part of your install flow, and "Read and change all your data on all websites" is going to stop feeling unusual.

That's exactly why it's worth knowing what it actually means before you click Accept.

Scan your extensions for broad permissions →


This article is based on publicly available developer documentation and news reporting. Extenshi does not independently verify all claims made by third-party vendors. 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].

Related Articles