Chrome 136 update breaks remote debugging functionality

Other Questions Headless Browser
1

I ran into issues after Chrome updated to version 136. The browser changed how it handles remote debugging switches like --remote-debugging-port and --remote-debugging-pipe. Now these flags get ignored when you try to debug using the default Chrome data directory.

The new requirement is that you must include the --user-data-dir switch pointing to a custom directory. Without this change, my automation script would just open a blank page and get stuck there.

I fixed it by creating a temporary profile directory for Chrome to use. Here’s the working code:

// Start browser instance
Console.WriteLine("Starting Chrome browser...");
var customProfileDir = Path.Combine(Path.GetTempPath(), "chrome-custom-profile");
var browserContext = await playwright.Chromium.LaunchPersistentContextAsync(
    customProfileDir,
    new BrowserTypeLaunchPersistentContextOptions
    {
        Channel = "chrome",
        Headless = Convert.ToBoolean(ConfigurationManager.AppSettings["HeadlessEnabled"]),
        Args = new[]
            {
                "--disable-web-security"
            }
    });

var newPage = await browserContext.NewPageAsync();

Anyone else dealing with this Chrome 136 debugging restriction?

2

ugh this update messed up my testing pipeline too. chrome just sits there doing nothing now without the custom profile dir. really wish they’d give us some warning about these breaking changes instead of just pushing them out silently.

3

This caught me completely off guard too since my selenium grid setup just started failing without any obvious reason. What’s particularly annoying is that Chrome 135 was working perfectly fine with the same configuration. I ended up having to modify all my docker containers that were running headless Chrome instances. The temporary directory approach works but I found that explicitly setting a persistent user-data-dir path gives more consistent results, especially when running multiple parallel sessions. One thing to watch out for - make sure you’re properly cleaning up these custom profile directories or you’ll end up with disk space issues over time. I also noticed that some Chrome extensions behave differently when using custom profiles, so that might be something to test if your automation relies on specific browser functionality.

4

Had the exact same problem hit me yesterday when my scraping scripts suddenly stopped working. What caught me off guard was that Chrome didn’t throw any error messages - it just silently ignored the debugging flags which made troubleshooting a nightmare initially. The workaround with custom user data directory definitely works, though I noticed it creates some overhead since you’re essentially spinning up a fresh profile each time. For production environments, I’d recommend setting up a dedicated profile directory that you can reuse rather than generating temp folders constantly. Also worth mentioning that this change seems to be related to Chrome’s enhanced security measures, so we might see similar restrictions rolled out to other debugging features in future updates. The documentation hasn’t been updated yet to reflect this requirement which is frustrating.