Chrome 137 removed the "--load-extension" option. (Major situation!)

[mdmintz]

Chrome 137 removed the --load-extension option. (Major situation!)

Specifically, Chrome-branded Chromium removed the --load-extension option in Chrome 137. (This doesn't affect Chrome-for-Testing, unbranded Chromium, or other Chromium browsers such as Brave.) Note that Chrome extensions are used for various functionality, such as auth proxy, the Recorder, and other major features!

Required reading on the situation:

• [🐛 Bug]: Chrome team removes --load-extension switch on Chrome builds SeleniumHQ/selenium#15788

• https://support.google.com/chrome/a/answer/7679408?sjid=11437610768047552203-NA#chromeBrsrE137

• https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/UWP4-k32AgAJ

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

Obviously, this is a major problem because regular Chrome is the stealthiest for UC Mode / CDP Mode, and many users (including myself) use UC Mode / CDP Mode with an authenticated proxy, which is set via extension. Going to need to find a workaround for this.

The good news is that the next version of Selenium will have BiDi-protocol, which should be able to work around this issue (SeleniumHQ/selenium#15788 (comment)). However, the bad news is that that release may be a month away. If people can, hold onto Chrome 136 in the meantime so that you can set the auth proxy with regular Chrome.

We appreciate your patience during this chaotic situation.

If you're not using UC Mode / CDP Mode (and you need to set the proxy), then you can use Chrome-for-Testing, (which is a Chromium browser), and that can be activated via --cft / cft=True.

And if you are using UC Mode / CDP Mode (and you need to set the proxy), then you may need to downgrade to Chrome 136 (if you can) in the meantime. I'll be working on a better workaround. You can also try using Brave by setting the binary_location. On a Mac, that would be binary_location="/Applications/Brave Browser.app/Contents/MacOS/Brave Browser". (It'll be in a different location on Linux and Windows.)

If you have other ideas, please add to this thread.
Major situation unfolding... All hands on deck!

[cgoldberg]

the next version of Selenium will have BiDi-protocol, which should be able to work around this issue. However, the bad news is that that release may be a month away.

This feature has already landed via SeleniumHQ/selenium#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

[mdmintz]

@cgoldberg Going to need expedited delivery on that Selenium 4.34 to regular PyPI.

[cgoldberg]

@mdmintz I know this breaks loading unpacked extensions via the --load-extension arg, but do you know if it also breaks loading packed extensions via ChromeOptions.add_extension?

SeleniumHQ/selenium#15788 (comment)

[mdmintz]

@cgoldberg That's broken too.

[mdmintz]

For anyone looking for a workaround, there are 4 so far:

• Stay on Chrome 136 if you can.
• Use Chrome-for-Testing if you don't need UC Mode / CDP Mode.
• Use Brave Browser by setting the binary_location (On a Mac, that would be binary_location="/Applications/Brave Browser.app/Contents/MacOS/Brave Browser")
• Go to chrome://extensions/ and directly load the unpacked extension that you want.

The possible 5th workaround would be to patch Chrome (just like chromedriver was patched into uc_driver).
If I can figure that out, that'll make regular Chrome allow loading extensions again, just like before.

[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.)

[VladShaternik]

Hello, everyone. I just faced the same issue and found a simple solution. Chrome team made a feature that disables --load-extension flag. So, we just need to disable that feature and everything works like before!

arguments.add("--disable-features=DisableLoadExtensionCommandLineSwitch")

Here are relavant chrome sources:

https://chromium.googlesource.com/chromium/src/+/290ed8046692651ce76088914750cb659b65fb17/chrome/browser/extensions/extension_service.cc#359

https://chromium.googlesource.com/chromium/src/+/HEAD/extensions/common/extension_features.cc#212

[mdmintz]

@VladShaternik That appears to be working! Thank you for figuring that out!

[mdmintz]

This was resolved in 4.39.1 - https://github.com/seleniumbase/SeleniumBase/releases/tag/v4.39.1

[cgoldberg]

This workaround will be short lived:
SeleniumHQ/selenium#15788 (comment)

I wouldn't suggest relying it for very long.