[🐛 Bug]: Chrome team removes `--load-extension` switch on Chrome builds

[vinaghost]

Description

They remove --load-extension that cause .AddExtensions() and other similar method broken

their commit https://chromium.googlesource.com/chromium/src/+/290ed8046692651ce76088914750cb659b65fb17%5E%21/chrome/browser/extensions/extension_service.cc

Version affected: Chrome 137

Reproducible Code

var options = new ChromeOptions();
options.AddExtensions(_extensionsPath);
var driver = new ChromeDriver(options);

Debugging Logs

[13564:10684:0524/222309.634:WARNING:chrome\browser\extensions\extension_service.cc:359] --load-extension is not allowed in Google Chrome, ignoring.

---

ℹ️ Last known working version: it broke on Chrome 137, worked on 136 and below

[selenium-ci]

@vinaghost, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[Delta456]

We probably would have to remove support for this method. We cannot deprecate this since the flag is removed in the Chrome itself

[vinaghost]

@Delta456, so no workaround?

[Delta456]

There isn't a workaround with CDP. You will have to downgrade Chrome version, though this will be available with BiDi. Java and Python will have them implemented by next Selenium release.

[vinaghost]

can new BiDirectional feature downgrade Chrome version ? or you mean it can help to enable the flag needed for --load-extension ?

[navin772]

@vinaghost you can still use --load-extension on non-Chrome branded builds like Chromium and Chrome for Testing. Thread - https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/UWP4-k32AgAJ

[cgoldberg]

can new BiDirectional feature downgrade Chrome version ? or you mean it can help to enable the flag needed for --load-extension ?

@vinaghost The BiDi feature will be a new way to load extensions. For a workaround right now, it looks like you will have to use an older version of Chrome (or else current version of Chromium or Chrome-for-Testing).

[cgoldberg]

this will be available with BiDi. Java and Python will have them implemented by next Selenium release.

Note to anyone using Python:

This feature has already landed via https://github.com/SeleniumHQ/selenium/pull/15749 (make sure to read the comments for the necessary startup flags needed to use it in Chrome).

To get it before the official Selenium 4.34 release, you can upgrade to the nightly release with pip install -U -i https://test.pypi.org/simple/ selenium

[cgoldberg]

They remove --load-extension that cause .AddExtensions() and other similar method broken

Looking at this more... this should only break "unpacked" extensions that are loaded via --load-extension arg. Selenium's methods for loading packed extensions via Chrome options doesn't rely on this. Can anyone confirm that this is actually broken in any of the bindings when using the AddExtension/addExtension/add_extension methods with Chrome 137?

If it still works, then we just need to update our documentation for loading unpacked extensions.

[selenium-ci]

@vinaghost, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[vinaghost]

@cgoldberg uhm, how do you load packed extension ? I followed this and this , it gave the result as above. I have 3 files crx and their path is in the _extensionsPath variable

var options = new ChromeOptions();
options.AddExtensions(_extensionsPath);
var driver = new ChromeDriver(options);

var list = new List<string>();

foreach (var extensionName in extensionNames)
{
   if (!extensionName.Contains(".crx")) continue;
   var path = Path.Combine(extenstionDir, extensionName);
   list.Add(path);
}
_extensionsPath = list.ToArray();

[cgoldberg]

@vinaghost so it must be broken for loading both packed and unpacked extensions. I'm not sure why packed extensions would be affected.

Also note... if you let Selenium Manager handle Chrome/Chromedriver for you, it will download Chrome-for-Testing, where extensions still work fine.

[oliverdunk]

I'm not sure why packed extensions would be affected.

I took a quick look at how this works in Selenium. If I'm understanding correctly, Selenium was passing --load-extension with the path to a CRX. That was actually just extracting the CRX file (CRX is a ZIP file with additional header data) and then loading the extracted folder as an unpacked extension.

[hadastoroP]

Help please :) My product, from C# used: options.AddArgument($"load-extension={WebContext.CurrentContext.ChromeExtensionPath}"); it loads an unpacked extension. It does not work on chrome version 137.

is there any simple solution? Does options.AddExtensions(_extensionsPath); also work for unpacked extensions?

[cgoldberg]

@hadastoroP neither of those currently work. You will have to stay on Chrome 136 or else switch to Chromium or Chrome-for-Testing.

[seleniumghost]

Thank you for all this information.

(This is the 2nd time now within some weeks where a change in productional Chrome/chromedriver stops us from updating it in automated testing environments. First was #396611138 (Chromedriver 133 creates an extra window handle when opening a pdf in a new tab) which took at first time to find it and then months (from 21.02.25 - 05.05.25) to get into the stable version of 136. Now the next version, 137, got the next big issue. I hope it won't take months again.

It's also sad that the reason mentioned in RFC survey for not using 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" did not get more attention and that the flag was thrown away without any prior deprecation notice or error/warning message. What a luck that we tested it before the productional update and found it by chance.)

[cgoldberg]

@seleniumghost if you have complaints about the chrome/chromedriver development or release process, raise them with Google or the Chromium project... they don't belong here.

[cgoldberg]

hah... someone just reported that this can be undone with this flag:

--disable-features=DisableLoadExtensionCommandLineSwitch

I just verified you can still use the old way of loading extensions if you start Chrome using this flag.

Should we add this by default to our Chrome Options? or just update the documentation that this is a workaround?

@oliverdunk is this going to remain working like this?

[vinaghost]

I confirm that it works

c# example

var options = new ChromeOptions();
options.AddExtensions(_extensionsPath);
options.AddArgument("--disable-features=DisableLoadExtensionCommandLineSwitch");
var driver = new ChromeDriver(options);

[oliverdunk]

@oliverdunk is this going to remain working like this?

This is part of the feature flag system we use to launch features. Unfortunately, that means it will go away once we are confident we no longer need a killswitch (usually they are around for no more than a few Chrome milestones).

Given that, I don't think this would be a good thing to document. It is only a temporary workaround and it is expected to break in the future at which point there would be the same issue.

[MagerDenis]

Confirm. Works in Java

ChromeOptions options = new ChromeOptions();
options.addExtensions("Filepath"));
options.addArguments("--disable-features=DisableLoadExtensionCommandLineSwitch");

[mattsmith321]

I confirm that it works

c# example

var options = new ChromeOptions(); options.AddExtensions(_extensionsPath); options.AddArgument("--disable-features=DisableLoadExtensionCommandLineSwitch"); var driver = new ChromeDriver(options);

Thanks for posting. Works for us as well when running tests locally and via Selenium Grid. We have Selenium Manager but trying to specify a specific version of Chrome was not working on the grid.

[mattsmith321]

@oliverdunk is this going to remain working like this?

This is part of the feature flag system we use to launch features. Unfortunately, that means it will go away once we are confident we no longer need a killswitch (usually they are around for no more than a few Chrome milestones).

Given that, I don't think this would be a good thing to document. It is only a temporary workaround and it is expected to break in the future at which point there would be the same issue.

Understood that this flag will go away at some point. But we need a workaround now and this works. I tried specifying the browser version to 136 which worked when running locally but did not work when running against Selenium Grid. We are using Selenium Manager so not sure why / where it wasn't working.

I do see that when running locally it indicates that it is running Chrome for Testing but I'm not sure what's running on the different nodes on the server.

[cgoldberg]

I do see that when running locally it indicates that it is running Chrome for Testing but I'm not sure what's running on the different nodes on the server.

If you don't install Chrome yourself and let Selenium Manager do it, it's downloading Chrome-for-Testing. Otherwise, it's using whatever you install and specify.

[caeduardo99]

I'm having the same problem loading the captcha solver extension for a bot with that version. When do you think the temporary fix will be available?

[cgoldberg]

@caeduardo99 The workaround for disabling the flag removal is available now. It's not a fix or change in Selenium.

[caeduardo99]

try: chrome_options.add_extension("C:\\Resolver.crx") chrome_options.add_argument("--disable-features=DisableLoadExtensionCommandLineSwitch") print(" Extensión Cargada Correctamente.") except Exception as e: print(f"Error al cargar la extensión: {e}") Running in Python

[SKumar-777]

I have confirmed that the following code works to load an unpacked Chrome extension:

var options = new ChromeOptions(); options.AddArgument("--load-extension=" + extensionPath);//Load unpacked extension options.AddArgument("--disable-features=DisableLoadExtensionCommandLineSwitch"); var driver = new ChromeDriver(options);

Will this continue to work in the future, or is it just a temporary workaround?

[cgoldberg]

I have confirmed that the following code works

We don't need continuous validation that the workaround currently works.

Will this continue to work in the future, or is it just a temporary workaround?

As stated in previous comments, it is temporary and will be removed from Chrome.

[SKumar-777]

Thanks @cgoldberg for the update.

I understand that, for now, we would need to either stay on Chrome 136 or switch to Chromium or Chrome-for-Testing.

Will the Selenium team be addressing this issue in the .NET C# library (like BiDi, other options)?