As of 2026, every Chrome extension on the Web Store ships under Manifest V3. The transition is over; the deadline passed; the extensions that did not migrate are gone. For AI extensions specifically — the rapidly growing category that includes voice assistants, chat sidebars, automation runtimes, and agentic browsers — the change has consequences that most install prompts gloss over. This post is the practical version: what Manifest V3 actually rules out, what it forces extension authors to be honest about, and how to read a 2026-era AI extension’s permission disclosure without taking the marketing copy at face value.
Where things stand in mid-2026
Google announced Manifest V3 in 2018, deprecated Manifest V2 across multiple phased deadlines through 2024 and 2025, and as of 2026 enforces V3 on every installable extension. The policy reasons (security, performance, privacy) and the political reasons (ad-blocker friction) have been debated to exhaustion elsewhere; we are not relitigating them here. The ground truth in 2026 is: every extension you install is a V3 extension. The interesting question is what that means for the AI category in particular.
What Manifest V3 actually changed
For users, three changes matter more than the rest.
- Service workers replace persistent background pages. Extensions can no longer keep a long-running background process alive at all times. They run in event-driven service workers that get spun down when idle. This makes some always-on behaviour harder to implement (and slower if forced).
- Remote code execution is banned. An extension cannot fetch JavaScript from the internet at runtime and execute it. Everything that runs has to be in the extension package submitted to the store and reviewed by Google.
- The host-permissions conversation is sharper. Chrome now distinguishes more clearly between “activeTab” (fires only when the user explicitly invokes the extension) and broad-host permissions (“read and change your data on all websites”). Users see this in the install prompt and in the per-site controls.
None of these are new concepts in 2026; they have been the rule for years. What is new is that there is no longer a Manifest V2 escape hatch. Every extension lives under these constraints.
What that means for AI extensions specifically
The AI category was unusually exposed to the V3 transition because many of the early entrants relied on patterns V3 disallows. The consequences in 2026:
- Background page-watching is harder. An AI extension cannot trivially keep a service worker alive observing every tab you open. Extensions that want to do this either design around the service-worker lifecycle (re-spinning on events) or accept that the “always watching” model is degraded by design.
- Bundled models are harder than they look. Because remote code execution is banned, extensions cannot download and run new model code at runtime; what is shipped is what the user gets, until the next store update. This also rules out a class of malware patterns that used to ship benign-looking extensions and remotely activate the bad behaviour later.
- The permission disclosure is more honest. Extensions that want to see your pages in the background must declare broad host permissions, and the install prompt will tell you so. Extensions that opted for activeTab cannot retroactively expand without prompting you again.
- The category split is now structural. Voice assistants and similar single-shot tools fit naturally into activeTab + on-press service worker. Chat sidebars and automation runtimes effectively require broad host permissions to deliver their value. The user-facing trade is now legible.
The permission conversation, post-V3
The single most useful thing a user can do with an AI extension in 2026 is read the permission line in its Chrome Web Store listing and ask: “does this match what the product needs?”
The two patterns are:
- activeTab only. The extension can see the current tab strictly when the user invokes it. It cannot background-watch. It cannot read the next tab you open. This is a narrow surface that suits voice assistants, single-shot rewriters, or tools whose value is “answer this one question.” Clicky uses this pattern.
- Host permissions across all sites. The extension can read and change every page you visit, in the background, all the time. This is the surface most chat sidebars and automation runtimes need to deliver their core feature (quick-action menu on every site, scheduled scrapes, multi-page workflows). It is more capability and more exposure; the trade-off is real.
Neither is dishonest. Both are now legible because the Manifest V3 install prompt makes them explicit. The 2026 question is not “is this extension safe?” — it is “does the permission scope match the value I expect to get from it?” A chat sidebar with broad-host permissions is defensible if you want a chat sidebar. A push-to-talk voice assistant with broad-host permissions would be a red flag, because it does not need them. Read the permission line; sanity-check it against the marketing copy.
We laid out a longer audit framework in Chrome Extensions That Do Not Track You; the V3 transition has made that framework more useful, not less.
Service workers vs persistent background pages
The technical heart of V3 is the service-worker model. In V2, an extension could keep a background page running indefinitely, watching events, holding state, polling APIs. In V3, the background script is a service worker that is spun up on events and spun down when idle. State has to be persisted somewhere (chrome.storage, IndexedDB) rather than held in memory.
For AI extensions this matters because some patterns become awkward. An always-listening voice assistant, for example, cannot cleanly keep a microphone stream alive in a service worker that Chrome is allowed to terminate. The cleaner V3 pattern is push-to-talk: the user explicitly invokes the extension, the service worker spins up, the microphone opens for the duration of the press, and the worker spins down again afterwards. We compared the two designs in detail in Push-to-Talk vs Always-Listening AI. The V3 lifecycle is one more reason the push-to-talk shape matches the platform.
No more remote code execution
The ban on fetching and executing remote code at runtime is the Manifest V3 change with the largest security upside and the smallest user-visible impact. In V2, an extension could ship a small loader and download arbitrary JavaScript from a remote server after install. That made store review easy to bypass — the extension Google reviewed was not the extension users ended up running.
In V3, every line of executable code has to be in the package submitted to the store. Updates require a new store submission and a new review. Some legitimate use-cases got harder (cloud-loaded themes, server-driven UI variants), but the security floor for the category is meaningfully higher in 2026 than it was in 2022. AI extensions that route requests to a remote model service are not affected — that is a network call, not remote code execution. What is banned is downloading new code the extension then runs. The model bill, the prompt, the API call all still happen over the network; they just do not result in new client-side code being loaded.
What a well-behaved 2026 AI extension looks like
Three signals worth checking before installing an AI extension on a machine that touches anything you care about:
- Permission scope matches the pitch. A voice assistant should ask for activeTab; a chat sidebar will ask for broad hosts; an automation runtime will ask for broad hosts plus a handful of platform-specific permissions. If the scope is larger than the pitch implies, ask why.
- The privacy policy names every third party. Where does the prompt go? Which model vendor processes it? Is there a separate text-to-speech vendor (most voice assistants use one)? Is there an analytics vendor? The policy should make all of these legible.
- Conversation memory is documented. Is the conversation stored server-side? For how long? Can you delete it? Is it stored at all? Session-only memory (the Clicky model) and persistent server-side history (the Monica/Sider model) are both reasonable; both should be disclosed.
Install checklist for users
- Read the permission line on the Chrome Web Store listing before clicking Add to Chrome.
- Open the privacy policy. Skim for: model vendor, retention period, third-party processors, opt-out for training.
- After install, go to
chrome://extensionsand check Site access. If the extension defaults to “On all sites” and you do not need that, switch it to “On click” or a per-site allowlist. - For sensitive sites (banking, healthcare, internal tools), consider a separate Chrome profile with no AI extensions installed at all.
Frequently asked questions
Is Manifest V3 actually more private than V2?
For honest extensions, yes — the permission disclosure is sharper, remote code is banned, and the service-worker model makes background watching less feasible. For dishonest extensions, the gap narrowed but did not close; a broad-host extension can still do almost anything to the pages it sees. V3 is not a substitute for reading the permission line.
Did Manifest V3 kill ad blockers?
It changed how they work — the declarative-net-request API replaces the more flexible blocking webRequest API for most cases — and the major ad blockers shipped V3 versions that work well enough for most users. It is the most-discussed example of a V3 trade-off, but it is not the topic of this post.
Can a Manifest V3 extension still use a remote AI model?
Yes. Manifest V3 bans remote code execution, not remote API calls. Sending a prompt to OpenAI, Anthropic, Google, or any other model provider is a network request — that is allowed and unchanged. What is banned is the extension downloading new JavaScript and executing it client-side.
What permission does Clicky request under Manifest V3?
activeTab only. The extension can see the current tab strictly when you hold the Alt key — never in the background, never on tabs you are not actively using. Memory is session-only. The product is intentionally designed within the narrow Manifest V3 permission lane, both for privacy and because the push-to-talk shape fits the service-worker lifecycle naturally.
Part of our push-to-talk & privacy series. See also Chrome Extensions That Do Not Track You and Push-to-Talk vs Always-Listening AI.