Fix Selenium Chrome session not created when reusing default profile: use non-default user-data-dir

Learn why Chrome blocks DevTools with the default profile and how to fix Selenium session not created: use non-default user-data-dir or Chrome for Testing.

When you run Selenium against Chrome to reuse a signed-in session, a common approach is to launch the browser with a specific user profile. Recently, that approach started failing for many setups with an error about remote debugging and data directories. If your tests suddenly stopped working when pointing Chrome to its default profile store, you are hitting a browser-side security change.

Minimal repro

The following snippet launches Chrome against the default profile store and a named profile. It aims to reuse saved cookies and passwords for a website, but ends up with a startup failure.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import time, os

DATA_ROOT = "C:/Users/LocalUserName/AppData/Local/Google/Chrome/User Data"
PROFILE_ALIAS = "Profile 1"

cfg = Options()
cfg.add_argument(f"--user-data-dir={DATA_ROOT}")
cfg.add_argument(f"--profile-directory={PROFILE_ALIAS}")
browser = webdriver.Chrome(options=cfg)

The launch fails with a message similar to the following and Selenium raises session not created:

DevTools remote debugging requires a non-default data directory. Specify this using --user-data-dir.

What actually breaks and why

This is the result of a recent Chrome change that tightens how DevTools remote debugging can attach when the browser is started with automation. The change comes from Chrome, not ChromeDriver. As the error states, Chrome refuses to start a DevTools-enabled session against the default user data store. Documentation from the Chrome team confirms the direction of these changes, and there were additional adjustments in v137 and up. The intent also touches increased security around saved cookies.

That explains the observed behavior. If you remove the profile flags entirely, Selenium starts fine because Chrome creates a fresh, non-default data directory for the automated session. But the target site is no longer logged in, because you are not reusing your saved profile data.

Workable paths forward

If you must use a real profile, there is an acknowledged workaround via Chrome For Testing described here: https://issues.chromium.org/issues/417456892. The broader background on the restriction is outlined by the Chrome team: https://developer.chrome.com/blog/remote-debugging-port. A related community write-up is also available: Selenium 4.32.0 does open chrome but doesn’t load the URL using my default profile.

There is also a practical adjustment that aligns with the error text. Since the default store is rejected, launch Chrome with a non-default user-data-dir and, if needed, point to a specific profile within that directory. You can prepare that directory and profile ahead of time and use it for automated runs.

Adjusted code example

The following snippet changes only where Chrome stores data. The key is to avoid the default location used by your regular Chrome instance.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

ALT_DATA_DIR = "C:/automation/chrome-data/userA"  # any non-default path you control
ALT_PROFILE = "Profile 1"  # use the profile that exists in ALT_DATA_DIR if applicable

opts = Options()
opts.add_argument(f"--user-data-dir={ALT_DATA_DIR}")
opts.add_argument(f"--profile-directory={ALT_PROFILE}")

driver = webdriver.Chrome(options=opts)

This satisfies Chrome’s requirement to use a non-default data directory for a DevTools-enabled session. If you opt to run without any profile flags at all, Chrome will create a fresh directory for each run, which also works but won’t preserve your signed-in state.

Why this matters for test stability

End-to-end checks that rely on persisted sign-in are sensitive to how browsers initialize their profile storage. A subtle security change in the browser can invalidate long-standing assumptions about profile reuse and push automated sessions into fresh, empty profiles. Knowing that this restriction comes from Chrome itself helps avoid chasing driver issues and points you toward supported strategies, including Chrome For Testing or a dedicated, non-default user-data-dir specifically for automation.

Takeaways

If your Selenium run fails with session not created alongside the DevTools remote debugging requires a non-default data directory message, you are hitting Chrome’s newer profile restrictions. Don’t point automation at the default user data store. Either use a non-default --user-data-dir that you manage for testing or apply the Chrome For Testing workaround referenced by the Chrome team. If you need a logged-in state, prepare that non-default directory and profile ahead of time and then reference it during your automated run. This keeps your day-to-day browsing separate, satisfies Chrome’s security constraints, and restores predictable test behavior.