Firefox is about to make file access opt-in — here's what breaks on July 21

Here's a quiet Firefox change that's going to trip up a lot of people two weeks from now, and almost nobody is talking about it.

Starting with Firefox 153 — scheduled to hit the release channel around July 21, 2026 (Mozilla release calendar) — extensions stop getting automatic file access to the local files you open in the browser. Every extension. Including the ones already installed and happily reading file:// pages today.

We run a catalog that tracks the permissions of every add-on across the Firefox, Chrome and Edge stores, so instead of guessing at the scale I just queried it. In our Firefox data, 25,569 extensions — a combined ~44 million monthly active users — request <all_urls> or explicit file:// host access, the permissions this change touches. That's the blast radius.

Inside it sits a much sharper core: 842 extensions explicitly declare file:// patterns in their manifests — the ones that clearly intend to read local files — and those alone account for ~15.5 million MAU. Not all of them will break, but all of them are in scope for the new rule.

What actually changes

Right now, when a Firefox extension asks for "Access your data for all websites" — the <all_urls> or file:///*/ host permission — file access rides along for free. Grant the website permission, and the extension can read the local files you open in the browser too. No separate prompt.

Firefox 153 severs that link. In Mozilla's own words:

"From Firefox 153, file access in extensions requires an opt-in for all extensions, including those already installed."

That's the whole change, and the "including those already installed" clause is the sharp edge. This isn't only a rule for new installs — extensions you've trusted for years lose their automatic file access the moment you update. Source: Mozilla's add-ons blog, WebExtensions API changes for Firefox 149–152.

Who feels it

Anything that reads files off your disk through the browser. Think PDF viewers and annotators, local-file tools, some downloaders, and content scripts that were injecting into file:// pages.

The clearest signal is the explicit-file:// set — extensions that wrote a file:// host pattern into their manifest on purpose. The biggest by users in our Firefox data: uBlock Origin (10.6M MAU, file://*/*), Easy Screenshot (1.3M), Bitwarden (944k, file:///*), IDM Integration Module (541k), Search by Image (425k), LanguageTool (361k), and MetaMask (309k).

Household names like AdBlock Plus, Privacy Badger, Dark Reader and Video DownloadHelper are in scope too, but only via <all_urls> — file access was riding along, not requested by name. Being on either list doesn't mean file access is core to the job; it means the new opt-in gate applies. If one of your daily drivers quietly stops doing something on a local page after the update, this is almost certainly why.

If you just use Firefox: turning file access back on

Nothing urgent, but know the symptom. After you update to 153, an extension that used to work on a locally-opened file (a PDF, an HTML file on your machine) may just... not, with no error and no obvious reason.

The fix is a two-click opt-in:

1. Open about:addons.
2. Click the extension, open its Permissions tab.
3. Flip on the file-access toggle if it's something you actually want reaching your local files.

And here's the upside: this is a genuinely good default. An extension quietly reading whatever file you open is exactly the kind of over-broad access that turns a useful add-on into a privacy problem the day it gets sold or compromised. Firefox making you say "yes" on purpose is the browser doing its job. Chrome has had its "Allow access to file URLs" toggle off-by-default for years; Firefox is closing the gap.

The move I'd make: treat July 21 as a prompt to actually look at what you've got installed. If an extension wants your files and you can't articulate why, that's your answer.

If you build Firefox extensions: don't get caught silent-failing

If your extension reads local files, the worst outcome is that it breaks for existing users on update and you find out from one-star reviews. Get ahead of it:

• Don't assume <all_urls> covers file:// anymore — after 153 it doesn't, on its own.
• Detect when file access is missing and surface a short in-product nudge pointing users to the about:addons opt-in, instead of failing silently.
• If file access isn't core to what you do, this is a fine moment to drop the permission entirely. Fewer permissions is a better store listing and a better trust score.

This lands alongside a related tightening earlier in the cycle: as of Firefox 152, executeScript() and registerContentScript() no longer inject into moz-extension:// documents (same Mozilla post). The direction of travel is clear — Firefox is steadily narrowing the implicit, ride-along powers extensions used to get for free.

The bigger picture

We just watched Chrome finish ripping out Manifest V2 in Chrome 150, and a lot of privacy-tool users treated Firefox as the refuge. Fair — but "refuge" doesn't mean "frozen." Firefox is tightening its own permission model too, just more quietly and one gate at a time. File access opt-in is the next one, and it arrives on July 21.

None of this is a reason to panic. It's a reason to know what your extensions can reach — before the browser starts asking on your behalf.

Not sure which of your extensions are asking for the keys to your local files? Scan your extensions on Extenshi → — we surface the exact permissions each one requests, across Firefox, Chrome and Edge, so you can decide what actually deserves the access.

How we counted

Two numbers, two queries — both run on July 12, 2026 against the 99,693 live Firefox listings in the Extenshi catalog:

• In scope — 25,569 extensions, ~44M combined MAU. Everything whose required permissions include <all_urls> or an explicit file:// host pattern. Before Firefox 153, <all_urls> matched file:// pages too — that's exactly the ride-along access the new gate removes.
• Explicit intent — 842 extensions, ~15.5M combined MAU. The subset that names a file:// pattern outright (file:///*, file://*/*, and variants). These are the ones most likely to actually lose a feature on July 21. Another 8 request file access as an optional permission — the pattern Mozilla wants everyone to move to.

Both are blast-radius counts, not breakage counts: how many extensions lean on file access day-to-day is smaller still, and you can't read that off permissions alone. MAU figures are store-reported and summed per set.

Sources

• Mozilla Add-ons blog — WebExtensions API changes for Firefox 149–152 (the behavior change and the exact wording quoted above)
• Mozilla release calendar — Firefox 153 release schedule (the July 21, 2026 target date)

---

This article is based on publicly available vendor documentation and release schedules from Mozilla. Extension counts and monthly-active-user figures come from the Extenshi catalog as of July 12, 2026. If you believe any information is inaccurate, please contact us at [email protected].