[🐛 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 #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");