Manifest V2 Is Finally Dead: What the End of the Enterprise Exemption Means

For most of the Manifest V3 transition, there was always one more escape hatch. When Chrome disabled MV2 for consumers, enterprise administrators could set ExtensionManifestV2Availability and keep their managed fleets running the old format. When that policy went away, power users could still flip ExtensionManifestV2Disabled from chrome://flags. Each forced-disable milestone arrived with a footnote: technically, you can still keep it alive. As of mid-2026, that footnote is being deleted from the source tree. The escape hatches are closing in sequence, and the last one is dated.

The Exemption That Outlasted Everything Else

ExtensionManifestV2Availability was the policy that mattered most, because it was the one with a legitimate reason to exist. Enterprises run internal extensions built against MV2 — line-of-business tools, security agents, custom workflow helpers — that were never going to be rewritten on Google’s consumer timeline. Google acknowledged this by carving out an exemption: managed machines could keep MV2 working past the dates that applied to everyone else.

That exemption was scoped to expire in June 2025, and it did. The policy was removed with Chrome 139 in mid-2025, alongside the broader stable-channel shutdown that began in Chrome 138 when the user-facing toggle disappeared entirely. The phase-out itself goes back further — Google began disabling MV2 in pre-stable Chrome 127 in mid-2024 and rolled it into stable Chrome from October 2024. But the enterprise policy was the piece that let the format survive in production environments long after consumer Chrome had moved on.

The practical meaning is blunt: there is no longer a supported configuration in which a managed Chrome deployment keeps Manifest V2 extensions running. If your organization deferred an internal-extension migration because the policy was still there, the deferral is over.

What’s Left, and When It Disappears

The reason migration advice written even a few months ago is now stale is that the remaining workarounds are being removed on a published schedule, and the dates are close.

• Chrome 150 (stable, expected June 30, 2026) removes ExtensionManifestV2Disabled, the chrome://flags toggle that power users relied on after the enterprise policy was gone. This is the change that ends the practical “keep uBlock Origin running” recipe that circulated through Chrome 138 and beyond.
• Chrome 151 (expected roughly four weeks later) strips the remaining MV2 infrastructure flags — ExtensionManifestV2Unsupported, ExtensionManifestV2Availability, and AllowLegacyMV2Extensions — from the codebase entirely.

A Google engineer confirmed the flag-removal timeline in a Chromium code review, so this is not speculation about Google’s intentions; it is a merge that removes the infrastructure. A limited DevTools method for forcing an MV2 extension to load still technically exists, but it requires manually re-patching page state every session and is not usable for day-to-day work. Once the flags are gone, there is no enterprise policy, no flag, and no hidden setting that restores MV2.

If you maintain documentation, an internal wiki, or onboarding notes that tell users to “enable MV2 from chrome://flags,” that guidance has an expiry date measured against the Chrome 150 stable rollout, not against some vague future.

Why This Lands Hardest on Content Blockers

The MV2-to-MV3 architectural shift has been covered exhaustively, including in our own Manifest V3 migration guide. The short version is that MV3 replaces the blocking webRequest API — which let an extension inspect a network request in JavaScript and decide, per request, whether to block or modify it — with declarativeNetRequest, where rules are declared ahead of time and applied by the browser.

For most extensions this is a manageable constraint. For content blockers it is the whole game. uBlock Origin’s effectiveness against modern advertising comes from dynamic filtering and large, frequently updated filter lists evaluated with per-request logic — exactly the capability declarativeNetRequest does not provide. Its developer has been explicit that an MV3 version cannot replicate the full feature set.

The fallback on Chrome is uBlock Origin Lite, a separate MV3 extension that works within declarativeNetRequest. It is a real tool, not a placeholder, but it drops dynamic filtering, much of the cosmetic filtering that defeats anti-adblock techniques, and the real-time request logger. Chrome users keeping the original extension alive through flags were holding onto the full version. After Chrome 150, that option is gone, and Lite is what remains on Chrome.

Firefox Did Not Follow

The cross-browser picture is the part most worth internalizing, because it changes the calculus for anyone whose threat model or workflow depends on full content blocking.

Firefox is not built on Chromium and is not bound by Google’s extension framework. Mozilla shipped its own Manifest V3 implementation but kept backward compatibility with the blocking webRequest API. The result: Firefox continues to support both Manifest V2 and the full version of uBlock Origin, with dynamic filtering intact. The full extension is also available on Brave, which is Chromium-based but has maintained its own blocking path.

So the situation as of mid-2026 is not “MV2 is dead everywhere.” It is “MV2 is dead on Chrome, and Chrome’s MV3 deliberately narrows what content blockers can do.” Those are different statements, and the difference is the entire argument for browser diversity. If full-strength blocking is a requirement rather than a preference, the platform decision now matters more than the extension decision.

What To Actually Do

The actions split cleanly by who you are.

If you maintain extensions: Treat MV2 as fully end-of-life on Chrome. There is no longer any Chrome configuration that runs it, so dual-targeting MV2 and MV3 for Chrome is wasted effort — ship MV3. For Firefox you can still rely on blocking webRequest, which is genuinely useful for tools that need per-request decisioning; just keep that Firefox-specific path isolated rather than assuming Chrome will ever restore the capability.

If you administer managed Chrome: Inventory every internal MV2 extension now, because the enterprise policy that was masking the problem is already gone. Anything still on MV2 is running on borrowed time that, after Chrome 150, expires. Audit manifest.json for MV2-only fields and budget the migration as real engineering work, not a config change.

If you rely on full content blocking: Decide whether uBlock Origin Lite’s reduced capability is acceptable for your use. If it is not, the realistic answer on Chrome is no longer “wait for a workaround” — it is to run a browser that still supports the full extension. Firefox and Brave both do.

Delete the chrome://flags instructions from your notes. They stop working when Chrome 150 reaches your channel, and the calendar for that is set.

FAQ

Can enterprises still use ExtensionManifestV2Availability to keep MV2 running? No. The policy’s exemption was scoped to June 2025 and the policy was removed with Chrome 139. Chrome 151 removes the last traces of it from the codebase.

What does Chrome 150 actually remove on June 30, 2026? The ExtensionManifestV2Disabled flag — the chrome://flags toggle that let users force MV2 extensions to keep loading after the enterprise policy was withdrawn. After this, the common power-user workaround stops working.

Is uBlock Origin Lite a drop-in replacement for uBlock Origin on Chrome? No. Lite works under declarativeNetRequest and drops dynamic filtering, much of the cosmetic filtering, and the real-time logger. It blocks ads, but with materially less capability than the full extension.

Does any of this affect Firefox? No. Firefox kept blocking webRequest support and continues to run both MV2 and the full uBlock Origin. The Chrome changes do not apply to it.