Как исправить ошибку DevTools в Selenium при использовании профиля Chrome

Ошибка session not created и DevTools в Selenium с Chrome: почему профиль по умолчанию не работает и как решить через user-data-dir или Chrome for Testing.

Когда вы запускаете Selenium с Chrome, чтобы переиспользовать уже авторизованную сессию, обычно запускают браузер с указанным пользовательским профилем. В последнее время этот подход начал ломаться у многих: появляется ошибка, связанная с удалённой отладкой и каталогами данных. Если ваши тесты внезапно перестали работать при указании Chrome на хранилище профиля по умолчанию, вы столкнулись с изменением политики безопасности в самом браузере.

Минимальный пример

Следующий фрагмент запускает Chrome с хранилищем профиля по умолчанию и заданным именем профиля. Идея — переиспользовать сохранённые cookies и пароли сайта, но запуск завершается ошибкой.

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)

Запуск падает с сообщением вида ниже, и Selenium выдаёт session not created:

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

Что именно ломается и почему

Это следствие недавнего изменения в Chrome, которое ужесточило правила подключения удалённой отладки DevTools при запуске браузера с автоматизацией. Изменение внесено в Chrome, а не в ChromeDriver. Как и сказано в сообщении, Chrome отказывается запускать сессию с включённым DevTools поверх хранилища пользовательских данных по умолчанию. Документация команды Chrome подтверждает это направление, а начиная с v137 и далее были дополнительные корректировки. Эти намерения затрагивают и усиление защиты сохранённых cookies.

Отсюда наблюдаемое поведение. Если полностью убрать флаги профиля, Selenium стартует нормально, потому что Chrome создаёт новый каталог данных не по умолчанию для автоматизированной сессии. Но целевой сайт уже не будет авторизован — вы не используете сохранённые данные профиля.

Рабочие варианты решения

Если вам нужно использовать реальный профиль, существует признанный обходной путь через Chrome For Testing, описанный здесь: https://issues.chromium.org/issues/417456892. Более широкий контекст ограничения изложен командой Chrome: https://developer.chrome.com/blog/remote-debugging-port. Доступен и связанный разбор из сообщества: Selenium 4.32.0 does open chrome but doesn’t load the URL using my default profile.

Есть и практичное решение, строго соответствующее тексту ошибки. Поскольку хранилище по умолчанию отклоняется, запускайте Chrome с нестандартным user-data-dir и, при необходимости, указывайте конкретный профиль внутри этого каталога. Такой каталог и профиль можно подготовить заранее и использовать в автоматизированных прогонах.

Изменённый пример кода

Ниже меняется только место хранения данных Chrome. Главное — не использовать стандартный путь, которым пользуется ваш обычный экземпляр Chrome.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
ALT_DATA_DIR = "C:/automation/chrome-data/userA"  # любой нестандартный путь, который вы контролируете
ALT_PROFILE = "Profile 1"  # используйте профиль, который существует в ALT_DATA_DIR, если применимо
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)

Это удовлетворяет требованию Chrome использовать нестандартный каталог данных для сессии с включённым DevTools. Если вы решите запускать вовсе без флагов профиля, Chrome будет создавать новый каталог для каждого прогона. Такой вариант тоже работает, но не сохраняет состояние входа.

Почему это важно для стабильности тестов

Сквозные проверки, завязанные на сохранённую авторизацию, чувствительны к тому, как браузер инициализирует хранилище профиля. Небольшое изменение безопасности в самом браузере может разрушить давние предположения о переиспользовании профиля и отправить автоматизированные сессии в чистые, пустые профили. Понимание, что ограничение идёт именно из Chrome, помогает не искать проблему в драйвере и подсказывает поддерживаемые стратегии — включая Chrome For Testing или выделенный нестандартный user-data-dir специально для автоматизации.

Выводы

Если запуск Selenium падает с session not created вместе с сообщением DevTools remote debugging requires a non-default data directory, вы упёрлись в новые ограничения профилей в Chrome. Не направляйте автоматизацию на хранилище пользовательских данных по умолчанию. Либо используйте нестандартный --user-data-dir, который вы контролируете для тестов, либо примените обходной путь Chrome For Testing, на который ссылается команда Chrome. Если вам нужен сохранённый вход, подготовьте такой нестандартный каталог и профиль заранее и подключайте их во время прогона. Это отделит повседневное браузирование, удовлетворит требования безопасности Chrome и вернёт предсказуемость тестам.