Impact of Chrome Manifest V3 on Browser Extension-Based Agents

Chrome’s Manifest V3 reshapes browser extension-based agents through three structural changes, which are ephemeral service workers, a ban on remote executable code, and declarative network request handling. Together, they turn architecture into a capability decision. Agents designed for user-invoked, resumable work fit the platform, while agents that depend on continuous execution or unrestricted network control face limits that a migration alone cannot resolve.

What Manifest V3 actually changed in Chrome's extension platform

In Manifest V3, event-driven service workers take the place of persistent background pages. A background context starts when an event triggers it and shuts down when idle. Execution is no longer assumed to be continuous. Separately, the remote code ban requires executable JavaScript to be bundled in the extension package submitted for store review and prohibits downloading and running it after installation.

The third change replaces blocking request handling through webRequest with the Declarative Net Request API, or DNR. Extensions give Chrome rules to apply instead of deciding for themselves whether to block each request. Google presents these changes as improvements to performance, security, and code auditability. Permissions also shape access through the distinction between user-invoked activeTab access and broad host permissions. As of 2026, every Chrome extension ships under MV3, with no remaining MV2 escape hatch.

How the transition unfolded and where it stands now

More than 85% of active extensions were already on MV3 by 2026, while the removal of MV2 support eliminated the remaining alternative. Chrome 138 disabled MV2 extensions for all users on July 24, 2025. Chrome 139 and later removed support that users could access, including the enterprise policy, and Chrome 150–151 removed the MV2 code that was left in June–July 2026. The Chrome Web Store removed all remaining MV2 listings on August 31, 2026.

Microsoft Edge began moving users off MV2 in August 2026, aiming to complete its consumer transition by the end of 2026. Because Edge inherits Chromium, the platform decision reaches across the Chromium ecosystem. Firefox gives developers another platform to choose from. Mozilla supports MV2 and MV3 concurrently and retains blocking webRequest, but agents targeting Chrome must now operate wholly within MV3’s constraints.

Why ephemeral service workers are the sharpest problem for agents

Under MV2, a background page could keep session state, task queues, and WebSocket connections in memory with no time limit. MV3 provides no chrome.runtime.keepAlive() method that restores that model. When Chrome terminates an idle worker, the agent cannot rely on that process to preserve its working state. Agents therefore need a different way to watch pages across tabs, keep a session going, and manage a multi-step task.

The architectural response is to make chrome.storage or IndexedDB the primary state layer, use chrome.alarms for scheduled reactivation, and make long operations resumable from stored checkpoints. State reconstruction adds latency when work resumes, with costs that compound across a multi-step workflow. Single-shot tools fit this lifecycle naturally because invocation, execution, and completion can form one bounded operation. Always-on agents fit less well, as an always-listening voice assistant illustrates. Keeping a microphone stream alive in a terminable service worker is not cleanly possible, whereas push-to-talk follows the platform’s event-driven model.

What the remote code ban means for agents that ship AI logic

Under MV2, an extension could fetch and execute JavaScript after installation, changing its behavior without another store review. Under MV3, changes to packaged executable logic require a new version and another review. That creates a release bottleneck for agents whose reasoning or site-specific behavior needs frequent improvement.

For local AI, bundled inference logic and model weights provide a way to keep computation inside that package. Bundled WASM follows this approach, while remote API inference moves the intelligence outside the extension. Remote inference keeps the extension thin but makes its intelligence dependent on an off-device service.

The security benefit addresses a specific abuse mechanism. An apparently harmless extension could previously fetch a malicious payload after review and become spyware. Requiring executable code in the reviewed package closes that route. The same restriction, however, prevents a legitimate agent from updating its packaged reasoning logic or adapting that code to a changed site layout without resubmission.

How DNR rule caps constrain agents that need to inspect network traffic

DNR changes where network decisions take place. With blocking webRequest, extension code could inspect a request before it left the browser and make a decision using current context. With DNR, Chrome applies declared rules rather than handing each blocking decision to the extension. Dynamic rules let extensions change some rules at runtime, up to the 5,000-rule cap. They do not restore arbitrary, content-sensitive decisions made by extension code for each request.

For agents, the loss extends beyond ad filtering. An agent may depend on a page’s API calls to detect state changes or follow a multi-step transaction. A declared ruleset cannot track those steps as the agent would. The uBlock Origin Lite FAQ illustrates the distinction by stating that dynamic filtering cannot be supported because DNR cannot apply rules according to the address-bar URL. The FAQ also explains that using webRequest as a workaround would constantly wake the worker. For agents with similar dependencies, the remaining paths are page-context observation through content scripts, a reduced capability, or an architecture outside the extension model.

The security argument for MV3 and the strongest objection to it

Packaged executable code gives the store an opportunity to inspect the code on every release, instead of reviewing an extension that can later replace its behavior through remote scripts. Google reported that approximately 42% of malicious extensions use the Web Request API. That figure establishes association, leaving open whether every such extension abused the API and whether MV3 eliminates malicious extensions.

The strongest objection concerns the platform owner’s incentives. Chrome’s owner is also one of the largest advertising networks, and restrictions on dynamic filtering narrow capabilities used to resist advertising. Runtime security alone cannot show the full effects of that conflict. Equally, a commercial benefit does not negate a genuine security improvement. For agent developers, both facts belong in the analysis, because a more auditable platform can also offer fewer useful capabilities. Neither observation settles the other.

What the uBlock Origin case reveals about the limits of extension-based agents

uBlock Origin demonstrates what happens when a widely used extension depends on capabilities the replacement platform does not preserve. The full extension reached an estimated 40 million Chrome users at its peak. Chrome began automatically disabling it on the stable channel in October 2024, before the later removal of the remaining MV2 routes. Its popularity could not preserve its underlying execution model.

Lite makes the resulting capability trade-offs visible. It ships with a fraction of the original’s filter lists and limits cosmetic filtering to Optimal and Complete modes, with generic cosmetic filtering off by default. Cosmetic filtering hides the containers that hold ads without blocking network requests. The developer also says it struggles with sites that actively detect and defeat ad blockers.

If persistent background operation or dynamic request handling is central to an agent’s value, removing it during migration can produce a different product. Features that fit MV3 can survive without that change in identity. Features that depend on prohibited behavior need a redesigned foundation or a delivery model beyond extensions.

How agent developers have adapted architecture within MV3's boundaries

Agent operations become resumable units, with meaningful state persisted before termination and scheduled reactivation handled through chrome.alarms. This pattern accommodates the runtime rather than trying to recreate an indefinite background page. Its cost is the work of checkpointing and reconstruction. Content script offloading addresses a different need by placing page-aware logic outside the service worker lifecycle, where it can observe page state and pass information back when needed.

Bundled WASM and model weights keep inference on-device, at the cost of package size and a release process tied to store review. Remote inference endpoints avoid bundled-weight limitations but introduce network dependency and move AI processing off-device. Neither pattern is a universal answer. OmniPic, part of OmniSuite, demonstrates meaningful local computation by performing image feature extraction and vector similarity search entirely client-side, with no image leaving the user’s device.

Permissions further divide the available design space. An activeTab extension sees the current tab when the user explicitly invokes it and cannot use that permission for background watching. Broad host permissions support reading and interacting with pages more widely, but expand the trust surface. Clicky AI uses the activeTab pattern for its own extension. This choice governs when an agent can observe its environment, making permission scope an architectural consideration as well as an install-prompt consideration.

Where MV3 extensions now compete with automation frameworks and cloud agents

MV3 strengthens the case for architectures outside the extension sandbox when agents need capabilities that the platform restricts. Playwright and Puppeteer operate at the browser API level. They are unaffected by MV3’s constraints and retain network interception, persistent state, and arbitrary logic execution. Cloud-based computer-use agents instead control a remote browser instance, which puts them outside the extension permission model.

Greater capability is not the only selection criterion. Extensions run locally within the user’s own browser session and pass through explicit store review, providing privacy and auditability properties that automation frameworks and cloud agents do not offer by default. Local execution does not, however, make an extension that uses remote inference an entirely on-device system. The compute decision still governs where that processing happens.

Brave takes a third route by using browser-engine filtering. That capability sits below the extension platform, beyond the boundary MV3 defines. Agents already designed around local processing, minimal permissions, and event-driven activation are better aligned with the extension option than agents ported from persistent MV2 designs.

What agent developers should take from MV3's constraint set as a design brief

Developers should begin with the agent’s required behavior when choosing an implementation. For work that fits MV3, developers should treat storage as the canonical state layer, design resumable operations, and make user invocation the natural starting point where the use case allows it. Single-session tasks, on-device inference, and user-triggered automation can still work within that model. Minimal permissions also keep the agent’s observable reach aligned with its stated purpose. These choices make the platform’s constraints explicit in the product before they surface as runtime failures.

The release model deserves the same early attention. Changes to executable extension logic require resubmission, making update cadence a deployment detail with product-level consequences. The permissions an agent asks for also need to match what it promises to do, because activeTab access and broad host access let agents do different things. An informed user can see that distinction in the install prompt. An agent promising background awareness through a user-invoked permission model has an architectural mismatch.

For features outside that profile, developers should check whether an extension that does less can still do the intended job. Always-on background monitoring and dynamic per-request control may justify an automation framework or another delivery model, while distribution and access to the user’s existing session may favor an extension. Neither choice is inherently superior. MV3 has made the boundary between what an extension-based agent can and cannot do clearer than before, which is useful architectural information even when the required capability falls on the uncomfortable side.