SessionNotCreatedException: Powerful Ways to Fix It Fast

The Error

org.openqa.selenium.SessionNotCreatedException:
  session not created: This version of ChromeDriver only supports Chrome version 120
  Current browser version is 131.0.6778.86

The message is unusually honest: your driver speaks version 120, your browser speaks 131. Selenium couldn't even open the browser, so no test step ran. This guide shows the quick fix, the permanent fix, how to stop it in CI, and the other causes that produce the same exception.

Why This Happens

ChromeDriver is the translator between Selenium and Chrome (see how WebDriver talks to browsers). Each ChromeDriver release is built for one major Chrome version.

The problem: Chrome auto-updates silently, roughly every four weeks. A driver you downloaded once and pinned does not. So a suite that passed on Friday fails on Monday with no code change — which is why this error feels so unfair.

The 30-Second Diagnosis

1. Read the last lines of the error: it tells you the driver version and the browser version.
2. Check your browser version at chrome://version.
3. Check which Selenium version your project really uses:
4. mvn dependency:tree -Dincludes=org.seleniumhq.selenium
5. Search your code for webdriver.chrome.driver. If it's there, that's almost certainly the cause.

The Permanent Fix: Stop Managing Drivers ⭐

Most guides tell you to download the matching driver. That's a treadmill, not a fix — you'll be back in four weeks.

Selenium 4.6+ — do nothing (best)

Selenium Manager is built into Selenium 4.6 and later. When you create a driver, it detects the installed browser version and downloads the matching driver automatically, caching it for next time.

// That's it. No driver path, no WebDriverManager, no download.
WebDriver driver = new ChromeDriver();

If you're on Selenium 4.6 or later and still set webdriver.chrome.driver, delete that line. A manual path overrides Selenium Manager and causes exactly this error.

// ❌ Delete this — it's why Selenium Manager isn't helping you
System.setProperty("webdriver.chrome.driver", "C:/drivers/chromedriver.exe");

Keep Selenium itself current:

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.27.0</version>   <!-- or the latest 4.x -->
</dependency>

Want a fixed, reproducible browser? Pin the version

Auto-updating Chrome is great for users and bad for test stability. Selenium Manager can also download a specific Chrome for Testing build, so the browser and driver stay locked together on every machine:

ChromeOptions options = new ChromeOptions();
options.setBrowserVersion("131");          // Selenium Manager fetches Chrome 131 + matching driver
WebDriver driver = new ChromeDriver(options);

Update the number deliberately, when you choose to — not when Chrome decides to.

Selenium older than 4.6 — use WebDriverManager (or upgrade)

<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>5.9.2</version>
    <scope>test</scope>
</dependency>

WebDriverManager.chromedriver().setup();
WebDriver driver = new ChromeDriver();

Upgrading to Selenium 4 is the better long-term move — it also brings the W3C protocol, relative locators and the new window API.

Fixing It in CI ⭐

CI is where this bites hardest, because the build agent's Chrome updates without telling anyone.

Option 1: Run the browser in a pinned Docker container

Selenium's official images ship Chrome and ChromeDriver together at matching versions. Start one as a service and point your tests at it:

# docker-compose.yml — browser and driver versioned together
services:
  chrome:
    image: selenium/standalone-chrome:4.27.0
    shm_size: 2gb
    ports:
      - "4444:4444"

ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(
    URI.create("http://localhost:4444").toURL(),
    options
);

Now the version pair is locked and reproducible — your build can't break because a machine somewhere updated. In a Jenkins pipeline, start the container before the test stage:

stage('Test') {
    steps {
        sh 'docker compose up -d chrome'
        sh 'mvn clean test -Dselenium.remote.url=http://localhost:4444'
    }
    post {
        always { sh 'docker compose down' }
    }
}

Read the URL from System.getProperty("selenium.remote.url") in your driver factory, so the same tests run locally (ChromeDriver) and in CI (RemoteWebDriver). The full setup, including parallel nodes, is in the Docker + Selenium Grid Guide.

Option 2: No Docker

Use Selenium 4.6+ so Selenium Manager follows the browser automatically, or pin the browser with setBrowserVersion() as shown above. Avoid disabling Chrome updates on shared agents — it just moves the problem.

Corporate networks and offline agents

Selenium Manager needs to download drivers (and, if pinned, browsers). If your network blocks those downloads, either allow the Chrome for Testing download hosts through your proxy, pre-install the matching driver on the agent image, or use the Docker approach — which needs no downloads at test time.

The Manual Fix (When You Must)

1. Check your Chrome version at chrome://version (or Help → About Google Chrome).
2. Download the matching driver from the Chrome for Testing dashboard. The old chromedriver.chromium.org downloads stop at version 114.
3. Match the major version: driver 131.x works with Chrome 131.x.

⚠️ This is a patch, not a fix — you'll repeat it every few weeks. Use Selenium Manager or Docker instead.

Other Causes of SessionNotCreatedException

It isn't always a version mismatch. Match the message:

The container essentials — these three flags prevent most Docker and CI start-up failures:

ChromeOptions options = new ChromeOptions();
options.addArguments("--no-sandbox");
options.addArguments("--disable-dev-shm-usage");
options.addArguments("--headless=new");

The Interview Answer

"SessionNotCreatedException with a version message means ChromeDriver and Chrome are incompatible — usually because Chrome auto-updated and the pinned driver didn't. Downloading a new driver each time is a treadmill. From Selenium 4.6, Selenium Manager resolves the driver automatically, so I remove any hard-coded driver path, and if I need a stable browser I pin it with setBrowserVersion. In CI, I run tests against a versioned selenium/standalone-chrome container so the browser and driver are locked together and builds are reproducible."

FAQs

What causes SessionNotCreatedException?

Usually a ChromeDriver/Chrome version mismatch — Chrome auto-updated, the driver didn't. It can also mean Chrome crashed on start-up, isn't installed, or a Grid had no matching node.

What's the permanent fix?

Use Selenium 4.6 or later so Selenium Manager resolves the driver automatically, and remove any System.setProperty("webdriver.chrome.driver", ...) lines, which override it.

Why does it break every few weeks?

Chrome auto-updates roughly monthly. A pinned driver goes stale silently — your code didn't change, the browser did.

How do I stop it in CI?

Run your tests against a versioned Docker image such as selenium/standalone-chrome, where Chrome and ChromeDriver are shipped together, or pin the browser with setBrowserVersion().

I get "Chrome failed to start: crashed" in Docker.

That's not a version issue. Add --no-sandbox and --disable-dev-shm-usage, and give the container more shared memory.

Does the same error happen with Firefox or Edge?

Yes — GeckoDriver and EdgeDriver can also fall out of step with their browsers. Selenium Manager handles Firefox and Edge the same way it handles Chrome.

Is WebDriverManager still needed?

Not on Selenium 4.6 or later — Selenium Manager does the same job built in. WebDriverManager is still useful if you're stuck on an older Selenium version.

Related

• Selenium Errors & Exceptions: The Complete Troubleshooting Guide
• Selenium WebDriver Fundamentals — how WebDriver talks to browsers
• Test Passes Locally, Fails in Jenkins — other CI-only failures
• Maven for Selenium: Lifecycle, pom.xml & CI
• The Complete Jenkins Tutorial
• Paste any error into the Selenium Exception Lookup for an instant explanation.