PSA: Removing `--load-extension` flag in Chrome branded builds

[Richard Chen]

Hi all,

Starting in Chrome 137, we will remove the ability to load extensions via the `--load-extension` command-line flag in official Chrome branded builds.

This follows our previous request for comment - we've closely looked at the feedback, and based on that feel that this should be a safe change for most developers. However, we have identified a few mitigations for specific use cases (more below).

Please note that this change only applies to Chrome branded builds. `--load-extension` will continue to function as before in non Chrome brands, such as Chromium and Chrome For Testing.

This change aims to enhance the security and stability of the Chrome browser for our users. 

We have observed that the `--load-extension` flag is commonly abused to load malicious and unwanted software into the browser.

What this means for your development workflow:

We understand that the `--load-extension` flag is a convenient tool for local development and testing. For those of you who primarily use Chrome branded builds,

• Consider Chromium or Chrome for Testing: The Chrome For Testing build is specifically designed for development and testing and will continue to support the `--load-extension` flag.

• Install extensions via the Chrome Extensions management page: On the Chrome Extensions management page (chrome://extensions), ensure "Developer mode" is enabled and then use the "Load unpacked" option to install your extension.

Some tools and libraries including web-ext currently rely on the `--load-extension` flag. We are working with maintainers where possible to release updates, and expect in most cases their functionality can remain unchanged.

In testing frameworks like Puppeteer, Selenium and Cypress, we are planning to publish updated guidance soon on how to load extensions in stable versions of Chrome.

We recognize that this might mean a slight shift in your usual process, and we truly appreciate your understanding as we work to improve the security of the Chrome ecosystem and protect our users from potential harm.

If you have any questions or concerns regarding this change, please feel free to reply to this email or reach out through our developer support channels.

Thank you for your understanding and continued dedication to building great extensions for Chrome users.

Thanks,

Richard on behalf of Chrome Counter Abuse

[Richard Chen]

Hi Athul, would Chromium builds be viable for your current workflow?

cc Oliver for the Selenium guidance status.

Best,

Richard

On Mon, May 12, 2025 at 10:09 AM Athul Devkar <athul....@okta.com> wrote:

Hi Team,

We confirm that --load-extension is no longer working for our Selenium tests following the changes in Chrome 137 branded builds.

Your announcement mentioned upcoming guidance: "In testing frameworks like Puppeteer, Selenium and Cypress, we are planning to publish updated guidance soon..."

Has this specific guidance for Selenium been published yet?

Please note that using chrome://extensions (Load unpacked) or Chrome for Testing are not viable options for our current workflow.

Thanks,
Athul Devkar

[Oliver Dunk]

Hi Athul,

Thanks for the reminder! I'll update the thread tomorrow.

My plan is to look at adding a method to Selenium like `install_extension()` which will hopefully make this fairly easy. Until then, I've been sharing examples of how to enable WebDriver BiDi (the new version of WebDriver) and therefore use some newer commands to install an extension.

Here's an example in the Python version of Selenium:

```

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

options = webdriver.ChromeOptions()

# Various flags needed to enable extension commands.
options.enable_bidi = True
options.browser_version = 'Canary'
options.add_experimental_option('enableExtensionTargets', True)
options.add_argument('--remote-debugging-pipe')
options.add_argument('--enable-unsafe-extension-debugging')

driver = webdriver.Chrome(options=options)

def webExtension_install(path):
    cmd_dict = {
        "method": "webExtension.install",
        "params": { "extensionData": { "type": 'path', "path": path } }
    }
    _ = yield cmd_dict
    return None

def install_extension(path, driver: webdriver):
  driver._start_bidi()
  driver._websocket_connection.execute(webExtension_install(path))

install_extension("extension", driver)

```

Let me know if this helps. I can hopefully provide similar examples for other languages if needed.

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

[Athul Devkar]

Hi Richard,

Sadly, Chromium builds won't work for us. :( 

Thanks,
Athul Devkar

On Mon, May 12, 2025 at 12:51 PM Richard Chen <ric...@google.com> wrote:

This message originated outside your organization.

---

[Athul Devkar]

Hi Team,

We confirm that --load-extension is no longer working for our Selenium tests following the changes in Chrome 137 branded builds.

Your announcement mentioned upcoming guidance: "In testing frameworks like Puppeteer, Selenium and Cypress, we are planning to publish updated guidance soon..."

Has this specific guidance for Selenium been published yet?

Please note that using chrome://extensions (Load unpacked) or Chrome for Testing are not viable options for our current workflow.

Thanks,
Athul Devkar

On Friday, April 4, 2025 at 11:13:39 AM UTC-5 Richard Chen wrote:

[Athul Devkar]

Thanks for the quick response and details. Some follow-up questions:

1. Do you have an estimated timeline for when the official install_extension() method might be available in Selenium-Java?
2. Could you please provide a Java example for the current BiDi approach, similar to the Python one you shared?
3. Regarding the browser version for the BiDi method: Is Chrome Canary a strict requirement at the moment, or is there a possibility it would work with recent Stable or Beta versions (which we primarily use for testing)?
4. Is WebDriver BiDi the intended primary mechanism for Selenium to handle extension installation in branded Chrome builds going forward (as an alternative to the deprecated --load-extension flag)?

Thanks,
Athul Devkar

On Mon, May 12, 2025 at 1:10 PM Oliver Dunk <olive...@google.com> wrote:

This message originated outside your organization.

---

[Oliver Dunk]

Ah, I didn't realise the mailing list was still on the CC here.

I'll give a general update for the benefit of everyone and then reply to your questions.

Puppeteer

The latest release contains new methods to make it easier to load extensions. You can find all of the details here: https://pptr.dev/guides/chrome-extensions.

This works across all Chrome channels, and should hopefully be a fairly easy switch for anyone with existing tests.

Selenium

I also think similar changes would make sense in Selenium, and there's a related open issue here: https://github.com/SeleniumHQ/selenium/issues/15585. One thing I do want to stress is that I don't believe anyone on the Selenium team has committed to adding this yet. I would assume they will be supportive but of course it is ultimately up to them if they want to add this.

There's no specific timeline for this. I'd like to try and make some progress since Chrome 137 is nearing stable, but I can't promise anything right now.

Cypress

I haven't personally had a chance to look at the situation here, but a Cypress team member mentioned in another thread that they were interested in keeping this working: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/hgJBUMlRCAAJ. I'll follow up.

FAQ

Do you have an estimated timeline for when the official install_extension() method might be available in Selenium-Java?

I don't have anything specific to share, and as mentioned this does ultimately depend on if this is a feature Selenium would like to support. However, I did notice a community PR which is a promising sign. I'll post on the issue to see if I can help in any way.

Could you please provide a Java example for the current BiDi approach, similar to the Python one you shared?

I think this should be possible - I'll experiment with this tomorrow.

Regarding the browser version for the BiDi method: Is Chrome Canary a strict requirement at the moment, or is there a possibility it would work with recent Stable or Beta versions (which we primarily use for testing)?

At this point, I think it should work for all channels. That is definitely the intention, there was just a brief period when I first wrote that sample where the new BiDi methods hadn't propagated through channels yet.

Is WebDriver BiDi the intended primary mechanism for Selenium to handle extension installation in branded Chrome builds going forward (as an alternative to the deprecated --load-extension flag)?

Now the flag is being removed, there are two remaining options to load an extension:

• Using the Chrome DevTools Protocol: https://chromedevtools.github.io/devtools-protocol/tot/Extensions/#method-loadUnpacked
• Using WebDriver BiDi: https://www.w3.org/TR/webdriver-bidi/#command-webExtension-install

I'm not sure what would make the most sense for Selenium, but generally WebDriver BiDi is the future for this sort of thing, and my understanding is that we hope the maintainers of testing libraries feel similarly.

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

[Oliver Dunk]

Hi Jennifer,

Apologies, of course that wasn't our intention.

Please feel free to reach out with questions wherever is the most convenient for you. We'll do our best to support your team in any way we can.

You can also email me directly if you think that would be helpful.

Thanks,

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

On Mon, May 12, 2025 at 8:29 PM Jennifer Shehane <jenn...@cypress.io> wrote:

Hi, our team was notified via the Cypress issue that was opened. This is a really aggressive timeline for us. We didn't know this thread existed with this announcement as we were following the original RFC that did not provide an update on timelines. Would you prefer that we respond through this group or the Cypress issue?

[Jennifer Shehane]

Hi, our team was notified via the Cypress issue that was opened. This is a really aggressive timeline for us. We didn't know this thread existed with this announcement as we were following the original RFC that did not provide an update on timelines. Would you prefer that we respond through this group or the Cypress issue?

On Monday, May 12, 2025 at 2:52:04 PM UTC-4 Oliver Dunk 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.