Hi @oliverdunk. I just want to clarify that Chrome 137 is expected to be released in 2 weeks and our team has those two weeks to navigate this large change, it's implications, test at scale, and make sure there are no regressions for our users?

Hi @AtofStryker - I appreciate that it's a quick rollout, which is in part is because we were seeing the flag actively being abused. We did announce this as early as possible (coming up to six weeks ago) to try and give as much notice as possible. When we did an RFC, we also heard from most developers that they would be comfortable using Chrome for Testing, which hopefully means the impact of this isn't too broad.

That said, I'm very open to helping in any way I can. If you have any questions, feel free to ask here or reach out to me privately. I'd also be happy to see if I could open a PR if you don't have the bandwidth to work on this, I would just need to gain some familiarity with the codebase to figure out what would be needed.

Hopefully it's clear that we want to make this as little work for you as possible, and to keep supporting the genuine use cases while preventing this from being used maliciously.

Hi @AtofStryker - I appreciate that it's a quick rollout, which is in part is because we were seeing the flag actively being abused. We did announce this as early as possible (coming up to six weeks ago) to try and give as much notice as possible. When we did an RFC, we also heard from most developers that they would be comfortable using Chrome for Testing, which hopefully means the impact of this isn't too broad.

@oliverdunk I understand the urgency as there are security implications to allowing loaded extensions. That being said, weeks and not months for a large scale change is quite urgent for us 😅 so we are going to have to work together to come up with something quickly.

That said, I'm very open to helping in any way I can. If you have any questions, feel free to ask here or reach out to me privately. I'd also be happy to see if I could open a PR if you don't have the bandwidth to work on this, I would just need to gain some familiarity with the codebase to figure out what would be needed.

I think the easiest path of resistance is to use the CDP Extensions.loadUnpacked method to load the extension and theme, but it looks to require the --enable-unsafe-extension-debugging or --remote-debugging-pipe arguments. Do you happen to have documentation available on those arguments? It looks like the method is still not available after providing the --enable-unsafe-extension-debugging argument. Are you able to determine what is wrong here based on the following logs?

Hoping to get something up and running by EOD if we can 🤞🏻

Hopefully it's clear that we want to make this as little work for you as possible, and to keep supporting the genuine use cases while preventing this from being used maliciously.

We appreciate that. I am hoping we can come to a resolution ASAP.

I think the easiest path of resistance is to use the CDP Extensions.loadUnpacked method to load the extension and theme, but it looks to require the --enable-unsafe-extension-debugging or --remote-debugging-pipe arguments. Do you happen to have documentation available on those arguments?

So doing this requires both the --enable-unsafe-extension-debugging and --remote-debugging-pipe flags. It looks like you are connected with a port which would be the issue here.

Connecting over a pipe is definitely not quite as simple as with a port, but Mozilla recently added support to the chrome-launcher package which might be a good reference implementation: GoogleChrome/chrome-launcher#347

@oliverdunk Is this documented some place where I can see how these options work together and which other options may or may not work with these flags?

I don't think setting remote-debugging-pipe is going to be feasible, as a lot of the tooling we use relies on --remote-debugging-port and trying to lift that in 2 weeks I strongly believe is not going to be possible.

Our use case is a bit different, because we handle automation traffic through CDP in our server and also allow users to load extensions.

I am going to explore the BiDi route tomorrow morning. Are there any other possibilities here besides this?

@oliverdunk I had some time to explore BiDi and it looks like the Bidi -> CDP tab mapper is coming up? Is there a way to disable this? I found https://issues.chromium.org/issues/42323801 but it doesn't look like the issue has been addressed.

It also looks like the API client we use, webdriver, doesn't support the BiDi install methods yet so I created an issue webdriverio/webdriverio#14471

Using Windows, as of Cypress 13.16.0 (where %AppData% and %LocalAppData% are filled with the actual directories)

using npx cypress run.....the following is added to the Chrome binary Command Line
{SOME_NUMBER} is replaced by the actual run number

--load-extension="%AppData%\Cypress\cy\production\browsers\chrome-stable\run-{SOME_NUMBER}\CypressExtension,%LocalAppData%\Cypress\Cache\13.16.0\Cypress\resources\app\packages\extension\theme"

using npx cypress open.....the following is added to the Chrome binary Command Line

--load-extension="%AppData%\Cypress\cy\production\browsers\chrome-stable\interactive\CypressExtension,%LocalAppData%\Cypress\Cache\13.16.0\Cypress\resources\app\packages\extension\theme"

Cypress, by default, uses --load-extension as of the latest release

@oliverdunk Is this documented some place where I can see how these options work together and which other options may or may not work with these flags?

I don't believe we have any documentation which goes into more detail unfortunately. In general, I think any flags other than those used for pipe debugging should work.

I don't think setting remote-debugging-pipe is going to be feasible, as a lot of the tooling we use relies on --remote-debugging-port and trying to lift that in 2 weeks I strongly believe is not going to be possible.

Yeah, that makes sense. I don't think there's an easy answer unfortunately but I completely understand the difficulty there.

I am going to explore the BiDi route tomorrow morning. Are there any other possibilities here besides this?

I think BiDi would be the best approach. As I'm sure you know, that's quite a major change but perhaps it is something you could make opt-in for extension developers and that would be a good compromise.

@oliverdunk I had some time to explore BiDi and it looks like the Bidi -> CDP tab mapper is coming up? Is there a way to disable this? I found https://issues.chromium.org/issues/42323801 but it doesn't look like the issue has been addressed.

I thought this was resolved, but I'm not sure. Let me ask a team member to follow up on this issue.

It also looks like the API client we use, webdriver, doesn't support the BiDi install methods yet so I created an issue webdriverio/webdriverio#14471

Oh, thanks for flagging this. I'll add that to the various libraries we are tracking that might be impacted and see if there is anything I can do to help.

@oliverdunk I had some time to explore BiDi and it looks like the Bidi -> CDP tab mapper is coming up? Is there a way to disable this?

I just confirmed and it should be hidden starting in Chrome 137: https://chromiumdash.appspot.com/commit/753acf9df872f629667c329dcfaf73677e8d9f93.

You can test that in beta, but of course it hasn't quite reached stable yet. Hopefully that's helpful though.

I think BiDi would be the best approach. As I'm sure you know, that's quite a major change but perhaps it is something you could make opt-in for extension developers and that would be a good compromise.

@oliverdunk I believe what we are trying to communicate is that Cypress has it's own unpacked unsigned web extension that we use to help our users test in what we call open, or headed mode. Additionally, we allow users to install their own extensions to test with Cypress. We have to support an approach here otherwise we do not have a web extension.

Luckily for us Cypress is mostly automated with CDP in chromium based browsers, but we use the extension for theming as well as our puppeteer plugin, which is going to break.

I don't believe we have any documentation which goes into more detail unfortunately. In general, I think any flags other than those used for pipe debugging should work.

Yeah, that makes sense. I don't think there's an easy answer unfortunately but I completely understand the difficulty there.

I thought this was resolved, but I'm not sure. Let me ask a team member to follow up on this issue.

Cypress supports the last 3 versions of any major browser. Firstly, all older versions of our binary likely will not work with Chrome 137+, which is disruptive. Secondly, Cypress is likely going to need to flex on version to use either --load-extension or another method, likely BiDi at this moment, because the experience is not up to par with the Bidi/CDP bus displaying in Chrome 136 and under. The extension methods for BiDi aren't supported yet by the node webdriver client so they need to be added. Or we need to communicate with the websocket directly 🙁 .

Either way, we are looking at work that is going to take longer than 2-6 weeks to complete. Respectfully, I don't understand how this tight of a deadline can be expected given the state of the surrounding ecosystem, lack of documentation and migration paths, and fulling understanding the implications of current migration paths that we need to discover on our own.

To comply, we are likely looking at a loss of functionality until we are able to support quality work arounds for our users. Personally, I don't see how this is acceptable, especially from a major browser such as Google. The team will be discussing options today and tomorrow and are going to try to forge a plan around this.

For reference, Cypress recently migrated Firefox to Webdriver BiDi with the help of @whimboo from the Mozilla team. The effort took months to guarantee a seamless transition for our users with a lot of back and forth collaboration.

@oliverdunk we are planning to do #31702 and #31703 to address the removal of --load-extension in Chrome branded.

Currently, it looks like the --load-extension argument is a no-op in Chrome 137 Beta. Will this be the case during release?

Also, just to confirm, --load-extension will continue to work in Chrome for Testing and Chromium, correct?

Thanks @AtofStryker for the continued updates.

I've just sent an email to @jennifer-shehane (I didn't have your email address) to see if there is any more help we can provide. Feel free to reply there if it would be useful.

Currently, it looks like the --load-extension argument is a no-op in Chrome 137 Beta. Will this be the case during release?

Yes, it will be a noop that will also log the following as a warning to stdout: --load-extension is not allowed in Google Chrome, ignoring.

Also, just to confirm, --load-extension will continue to work in Chrome for Testing and Chromium, correct?

Yes, only "branded" builds of Chrome are impacted which does not include Chromium or Chrome for Testing.

Just to confirm our actions at the moment, in order to address this quickly enough for the Chrome 137 release:

We will throw an error if someone is using the @cypress/puppeteer plugin or the launchOptions.extensions API in Chrome 137+ - because those features will not work in Chrome 137+ - so we want them to be notified instead of silently failing. For all other users not using these packages/APIs Cypress will work the same as before for Chrome branded browsers. #31703

The theming of our extension will no longer work, but this will not impact functionality of the Cypress App. #31704

We will continue to gather feedback from users on how disruptive this change is. If it becomes a priority to add back this functionality, we'll consider our options at that time. At the moment, the available options are not viable for what Cypress requires.

Just as a cross-check, in addition to any tests that the Cypress.io team are doing, I successfully ran https://github.com/cypress-io/cypress-example-kitchensink against Chrome Beta using Cypress 14.3.3 (current latest) on Ubuntu 24.04.2 LTS, Node.js 22.15.0 LTS

Chrome Beta
  - Name: chrome
  - Channel: beta
  - Version: 137.0.7151.15
  - Executable: google-chrome-beta
  - Profile: /home/mike/.config/Cypress/cy/production/browsers/chrome-beta

  │ Cypress:        14.3.3                                                                         │
  │ Browser:        Chrome Beta 137 (headless)                                                     │
  │ Node Version:   v22.15.0 (/home/mike/n/bin/node)                                               │
  │ Specs:          20 found (1-getting-started/todo.cy.js, 2-advanced-examples/actions.cy.js, 2-a │
  │                 dvanced-examples/aliasing.cy.js, 2-advanced-examples/assertions.cy.js, 2-advan │
  │                 ced-examples/connectors.cy.js, 2-advanced-examples/cookies.cy.js, 2-advanced-e │
  │                 xamples/cypress_api.cy....)                                                    │
  │ Searched:       cypress/e2e/**/*.cy.{js,jsx,ts,tsx}                                            │
 
 ✔  All specs passed!                        01:20      123      123 

Updated search to include @cypress/puppeteer. This can only search public GitHub repos, not private ones. It does not account for Cypress repos held elsewhere, like on GitLab.

• (--load-extension OR launchOptions.extensions OR "@cypress/puppeteer") AND chrome cypress NOT is:archived has 527 hits, compared to
• chrome cypress NOT is:archived with 188k hits

Assuming this is representative of unsearched repos, Chrome 137 change would then impact 0.2% of repos.

@MikeMcC399 Yah, we are expecting these uses to be a smaller percentage