RFC: Removing the `--load-extension` flag in branded Chrome builds

[Oliver Dunk]

Hi all,

We're looking for feedback on how you use the `--load-extension` flag in Chrome. This allows you to start Chrome with an unpacked extension from the command line.

We know this is used for development, and some popular tooling like web-ext, but it is unfortunately commonly abused to load malicious and unwanted software. As a result, we are evaluating additional restrictions on its usage. We need to do more than restricting this to developer mode as that is unfortunately too easy for software to bypass.

One approach we are considering is restricting this to non-Chrome branded builds like Chromium and Chrome for Testing. Tooling could automatically download these builds to continue supporting specific workflows. We have no plans to remove the "Load Unpacked" button on the chrome://extensions page.

We'd love to know:

• How do you currently use the `--load-extension` flag?
• Would you be able to use Chrome for Testing or Chromium for your use cases?
• Would this change add significant friction to your development, and if so, in what ways?

Even a brief comment is helpful. We'd really like to understand usage in the ecosystem more before we decide on a path forward.

Thanks,
Oliver on behalf of Chrome Extensions DevRel

[Moe Bazzi]

Thanks! Here is my response:

• How do you currently use the `--load-extension` flag?

• with Playwright, using Chromium and Chrome For Testing for automated testing around my chrome extension

• Would you be able to use Chrome for Testing or Chromium for your use cases?

• yes

• Would this change add significant friction to your development, and if so, in what ways?

• no

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/7f8fd3e5-3fd3-4186-bf97-5c96bfff6c52n%40chromium.org.

[Alexei Miagkov]

Privacy Badger uses it in Selenium tests [*] and for scanning the web with Badger Sett, Privacy Badger's training project.

It would be unnacceptable to restrict this ability to a special test-only version of Chromium. We need to test and crawl the web using the same versions of Chrome used by regular Chrome users.

[*] https://github.com/EFForg/privacybadger/blob/9af0fd29ea54dfe31a5e2f11745237c46a02a3e5/tests/selenium/pbtest.py#L166

[Peter Bloomfield]

In principle, we'd be very happy to see more built-in safeguards around the command line flags. We've had to write software to let our customers block some flags which can override enterprise policies, such as "--disable-extensions".

However, disabling the --load-extension flag unilaterally on the standard Chrome release would probably cause us some challenges, and increase risk for our release process. Perhaps that flag could be allowed if Dev Tools are explicitly enabled by enterprise policy?

During development and testing, we only use the normal version of Chrome, not Chrome for Testing. The reason is that we want to be as certain as possible that we're getting the same results as customers would get, in particular around performance. Since migrating to mv3, we've had major problems with inconsistent performance of extension code, so I'd be very wary of switching to a different browser build in case we miss something. (Performance is a critical concern because we're using the web request blocking API -- if our extension runs slowly then it degrades the entire browsing experience for the end user.)

Part of our development and testing workflow involves using our own scripts to load our extension into Chrome via the command line. The scripts do various other things, like allow-listing the extension so it can access enterprise-only APIs, and setting up sandboxed user data directories so we can test different builds side by side. Having to add a manual step to load the extension would certainly cause some friction.

[Vlas Bashynskyi]

Hello, I currently use the --load-extension flag in automated end to end tests for several chrome extensions.
I didn't know Chrome for Testing existed, but it looks like it should be able to cover my use cases.
To reduce friction when doing automated testing - it would be great if Chrome DevTools Protocol had more methods related to extensions, like clicking the action icon, activating a context menu item, or changing allowed websites.
Thank you.

[xmcp]

We used `--load-extension` in a Selenium script to test behaviors related to extensions. Although using Chromium seems okay for this use case, it's unknown whether the Chromium will have the exact same behavior as Chrome stable, so it may cause troubles in the future.

I will suggest keeping this flag while showing a banner when this flag is present (similar to the current "Chrome is being controlled by automated test software" banner).

[Justin Wernick]

Hello,

Like several others, we're using `--load-extension` in Selenium to run automated testing of our extensions.

We use this not only for Chrome itself, but also other Chromium forks like Edge. I don't know how this change would affect Edge, but of course variants like Chrome for Testing and Chromium wouldn't be sufficient to test how Edge behaves.

Kind regards,

Justin Wernick

[Ursa Kacar]

I believe that as long as Chromium keeps the  `--load-extension` flag we should be OK- if the feature is only removed on Chrome, I don't see how that would affect Chromium based Edge, unless Edge browser later decides to also remove the option. Does that sound right or am I misunderstanding something?

For tests we run with selenium webdriver, we use Chromium, as Chrome binaries can be tricky to get.... We weren't aware of the Chrome for Testing, but it looks cool, and we'll try to see if we can use it instead of Chromium going forward. 

[Oliver Dunk]

Thanks everyone for the feedback so far.

A common theme seems to be the differences between normal Chrome builds and Chrome for Testing. I think that's a really fair question and honestly something I am still learning about. These are tagged for each release (Chrome Stable, Chrome Beta, Chrome Canary) and shouldn't be impacted by server side experiments, which actually makes them more deterministic and in some regards better to test against. As far as what flags are available / which channel they mirror, it is closest to a build of Chromium. The goal of Chrome for Testing is that it is the best fit for testing - it is used by default in tools like Puppeteer and if over time there are differences that are causing a lot of pain I think the team would be very open to looking into those.

With that said, I'll do my best to answer some of the specific questions...

However, disabling the --load-extension flag unilaterally on the standard Chrome release would probably cause us some challenges, and increase risk for our release process. Perhaps that flag could be allowed if Dev Tools are explicitly enabled by enterprise policy?

Thanks for sharing this. I believe there are cases where enterprise policy is set maliciously, so this would still leave things open to too much to abuse. I did mention it to the team though and we had a discussion about it, so I appreciate you bringing it up.

To reduce friction when doing automated testing - it would be great if Chrome DevTools Protocol had more methods related to extensions, like clicking the action icon, activating a context menu item, or changing allowed websites.

Yes, absolutely! We're actively working on this as part of the WebDriver BiDi project. We recently added support for loading unpacked extensions and in the future hope to look at some of the other things you've mentioned.

I believe that as long as Chromium keeps the  `--load-extension` flag we should be OK- if the feature is only removed on Chrome, I don't see how that would affect Chromium based Edge, unless Edge browser later decides to also remove the option. Does that sound right or am I misunderstanding something?

That sounds right - we're only making this change for branded Chrome builds :)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Alex]

Having had a look at Chrome for Testing, one major difference I discovered is that Chrome for Testing blocks third-party cookies.

This doesn't seem to be the "block third-party cookies" preference (controllable by enterprise policy), but the Privacy Sandbox third-party cookie phaseout thing. Can we turn this off via flags or policies? If we can, it's not clear how. This seems like a good time to mention that Google already backpedaled out of phasing out third-party cookies.

I also noticed that the new version of the extensions menu, the one that makes it really easy to break your extensions by clicking the permissions toggle while hiding the "pin" icon, the one thing that users will be interested in finding in this menu, is also enabled by default in Chrome for Testing.

I assume there are other differences, but we're already off to a bad start.

Rather than closely tracking the matching branded Chrome channel, Chrome for Testing appears to be treated as an experimental "let's enable all the flags that users may never seen in practice" build, regardless of channel/version number.

[Jennifer Shehane]

Hi, Cypress team member here. 

We expose an API to our users to load extensions within the browser they're testing. Under the hood, we're passing that extension path to a --load-extension arg that we pass to Chromium browsers (including branded Chrome if that's what the user chose to run the tests within). 

We could handle if this is no longer supported in Chrome branded browsers and throw an error for our users informing them to use Chromium or Chrome for Testing. 

Ideally there would be no change required for our users though - like there would be an option for us to load an extension by the path in some other way (like WebDriver Bidi) in ALL Chrome browsers.

We have many, many users who just do not feel comfortable testing on a browser that is not the exact browser that their customers are using. 

[Oliver Dunk]

Hi Jennifer,

Thanks so much for reaching out.

While we haven't made any final decisions yet, we would likely support the new Extensions.loadUnpacked CDP command in all builds. This is also available in WebDriver BiDi. In both cases, the command is only available if:

• The `--enable-unsafe-extension-debugging` flag is passed to Chrome.
• The connection to Chrome uses `--remote-debugging-pipe`, not `--remote-debugging-port`.

Is it possible this would work for Cypress?

Please also feel free to ping me privately and we can discuss more if that would be helpful.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[ghucz...@gmail.com]

Dear Oliver

FYI I use '--load-extension' in combination with '--enable-logging=stderr' for testing from a unix bash script. The script loads the extension, runs the tests, and then filters the chrome log to output progress and report success/fail as a unix error code.

This meshes nicely with other infrastructure scripts running from the unix command line. Chrome DevTools protocol isn't used at all.

Greg

[Panaya RD]

Hi Oliver, 

We are using selenium from a C# code.
and using options.AddArgument($"load-extension=...
This is an automation tool that opens a chrome page with selenium and adds our extension only to that chrome window.
since Chrome verson 137 the extension is not loaded anymore.
are there any quick fixes we can do to get the extension to get loaded on the selenium opened chrome?

Many Thanks,
Hadas.

[Oliver Dunk]

Hi,

The easiest option for now would be to continue using Chrome 136, or switch to Chrome for Testing: https://developer.chrome.com/blog/chrome-for-testing

I see you had a similar reply in the Selenium issue tracker which is where the Selenium team are looking into this: https://github.com/SeleniumHQ/selenium/issues/15788

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Alex]

I've since learned that it's possible to disable individual experiments with the --disable-features command line flag.

For example, --disable-features=TrackingProtection3pcd,HttpsFirstBalancedModeAutoEnable disables "Privacy Sandbox" third-party cookie restrictions as well as "example.com doesn’t support a secure connection" error pages on http-only websites.

Better yet, it appears that we can disable all Chrome for Testing on-by-default experiments with the --disable-field-trial-config command line flag.

On Wednesday, March 26, 2025 at 3:19:07 PM UTC-4 Alex wrote:

[Richard Chen]

Hi all, we just posted this new thread you might be interested in - `--extensions-on-chrome-urls` and `--disable-extensions-except` removals.

[Nick Sweeting]

Hi Chrome Extensions team —

I’m Nick Sweeting, the creator/maintainer of ArchiveBox (internet archiving). I understand the security motivation behind removing `--load-extension` in Chrome 137 and tightening other extension-loading flags, but this has severely impacted our internet-archiving automation use case.

ArchiveBox runs a single long-lived *branded* Chrome instance (we re-use any Chrome binary that users already have installed + need to match its fingerprint, UA, cookie behavior, etc.). We drive it via CDP from multiple cooperating processes that connect over CDP with `--remote-debugging-port`. We rely on extensions like Singlefile, ArchiveWeb.page, IStillDontCareAboutCookies, and several others to do our archiving, and we allow users to extend the system by adding more extensions to modify pages before archiving (e.g. TamperMonkey, uBlock, etc) if they need.

The current suggested alternative (`Extensions.loadUnpacked` / WebDriver BiDi `webExtension.install`) requires `--remote-debugging-pipe`, which is not workable for us because pipe-based DevTools doesn’t support our multi-process/multi-client orchestration model.

Could you reconsider providing an explicit opt-in escape hatch for this scenario in branded Chrome, e.g. a new command-line flag that re-enables programmatic unpacked extension loading while using `--remote-debugging-port`, with guardrails like:
- requiring a non-default `--user-data-dir` (we always use a dedicated, isolated profile directory)
- keeping `--enable-unsafe-extension-debugging` as an explicit acknowledgement
- warning UI if needed

References:
- https://github.com/puppeteer/puppeteer/issues/14536
- RFC: load-extension in branded Chrome builds: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/UWP4-k32AgAJ
- PSA: Removing `--load-extension` in Chrome 137: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/1-g8EFx2BBY
- Follow-on: Removing `--disable-extensions-except` / related flags (Chrome 139): https://groups.google.com/a/chromium.org/g/chromium-extensions/c/FxMU1TvxWWg
- Chrome Extensions blog note (June 2025): https://developer.chrome.com/blog/extension-news-june-2025
- Note on pipe requirement for extension install: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/hgJBUMlRCAAJ

Thanks for your consideration.

--From Nick

[Oliver Dunk]

Hi Nick,

Thanks for reaching out.

Some of the guardrails you mentioned are alternative options we considered, however I don't think it is likely we would implement those now. They are less effective than removing these flags entirely, and at this point the change has been rolled out for over six months.

Have you considered having an intermediate WebSocket process that acts as a middleman and passes CDP commands along to the pipe? Without changes to Chrome that seems like it might be the option here that minimizes the number of changes you need to make to your architecture.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB