In Selenium, what does a session not created error saying ChromeDriver only supports Chrome version 141 mean?
answer
- Two version numbers in one message
- The session never actually started
- One executable, one browser major
- Something updated itself overnight
- Driver and browser majors must match
basics
~10 sIt means the ChromeDriver executable and the Chrome it launched are on different major versions. ChromeDriver drives one Chrome major only, so it rejects the new-session request before any page is loaded.
solid answer
~40 sIt means the `chromedriver` executable on the machine and the Chrome it launched are on different **major** versions, so ChromeDriver refused the new-session request. In Selenium 4 the Java client raises `SessionNotCreatedException` from `new ChromeDriver(...)`, before the seat-map page is ever requested, so every case in the suite fails identically. The message also prints `Current browser version is ...` and the browser binary path, which tells you exactly which Chrome started. The usual cause is Chrome auto-updating past a driver that was downloaded once and never moved. Fix it by installing the driver published for the Chrome major now on the machine, then keep both halves pinned to one version so it cannot drift again.
go deeper
Be ready to say in one sentence that the driver and the browser are on different major versions, and to point at the two numbers in the message that prove it. Recognising it instantly saves an hour.
Explain why the rule exists: each ChromeDriver build is compiled against one Chrome major and checks the browser it started, so the mismatch is refused deterministically at the new-session command.
Move past the fix to the cause. An auto-updating browser against a driver nobody moves will do this again, so demonstrate pinning both halves and recording the pair each run used.
Frame it as an environment-reproducibility question: which version pair the organisation's browser runs stand on, who owns moving it, and what evidence a green run should carry about the browser that produced it.
## Where the error comes from `ChromeDriver` is a separate executable that speaks the W3C WebDriver protocol to your Selenium code on one side and Chrome's own automation interface on the other. That second side changes with the browser, so every ChromeDriver build is compiled against a single Chrome **major version**. Before it hands back a session id it starts Chrome, asks the browser what version it is, and refuses the request when the major is not its own. In Selenium 4 the Java client turns that refusal into `SessionNotCreatedException`, thrown from the line that constructs the driver — `new ChromeDriver(...)` — so the seat-map page is never requested at all. ## Reading the message The text carries everything you need: - `This version of ChromeDriver only supports Chrome version 141` — the major the **driver** on disk was built for. - `Current browser version is 142.0.7444.60` — the full version the **browser** reported when it started. - `with binary path /usr/bin/google-chrome` — **which** Chrome was launched, which matters when a machine has more than one. - The two majors, `141` against `142`, are the only comparison that decides the outcome; the trailing build numbers never do. ## Why it appears with nobody changing the code Chrome updates itself quietly in the background and applies the update on its next restart. The driver sits on disk exactly where it was put. So a suite that opened the airline seat map every night for a month can fail on a Tuesday because the browser crossed a major boundary overnight while the driver did not. There is no commit to blame, which is why this error is worth recognising instantly: the fastest route to the cause is reading the message rather than searching the diff. | Browser | Driver executable | Version rule | |---|---|---| | Chrome | `chromedriver` | one matching major; a mismatch is refused at new session | | Edge | `msedgedriver` | one matching major, with a message of the same shape | | Firefox | `geckodriver` | a documented **minimum** Firefox version, so it spans a range | ## What this error is not - Not a locator problem. Nothing reached the seat map, so no `By` was ever evaluated. - Not a timing problem. No wait can help a session that was refused before it existed. - Not flakiness. The refusal is deterministic: every case in the suite fails, every time, with the same text. - Not a Selenium bug. The client faithfully reports what the driver said; the version pair on the machine is what is wrong. ## Fixing it 1. Read both numbers from the message — the supported major and the browser's actual version. 2. Install the `chromedriver` published for the browser major that is actually on the machine, or move the browser back to the driver's major; either restores the pair. 3. Confirm the fix by starting one session and printing `Capabilities.getBrowserVersion()`, rather than by rerunning the whole suite. 4. Stop it recurring by pinning both halves to one version — a browser build that does not auto-update, plus the driver published alongside it — and upgrading them together. ## Confirming which Chrome actually started Before changing anything, prove which two executables are involved. The message already names the browser path, and the driver's own version is one command away: - Run the driver with `chromedriver --version`; it prints the build and the Chrome major it was made for. - Ask the browser at the path from the message what it is, rather than the one you assume is installed. - Check whether an earlier `chromedriver` is shadowing yours on `PATH`, or whether a `webdriver.chrome.driver` system property in the run configuration points at an old copy. - After the fix, start one session and print `Capabilities.getBrowserVersion()` instead of rerunning the whole seat-map suite to find out. That sequence takes a minute and removes the guessing. Most of the time it turns up something mundane: a driver downloaded months ago sitting next to a browser that has quietly moved four majors since. ## Why interviewers ask a junior this It is the first error almost everyone meets on a real Selenium project, and the answer shows whether a candidate reads an exception or reacts to it. A weak answer reaches for a rerun or starts editing the seat-map page object. A good answer says, in one sentence, that the driver and the browser are on different majors, points at the two numbers in the message that prove it, and knows the failure happened at session creation and not on the page. Interviewers also listen for the follow-on instinct: that a fix which only restores today's run leaves the same trap armed, and that the pair should be pinned rather than repaired again next month.
- Does the same strict rule apply to Firefox and Edge?Edge behaves like Chrome: `msedgedriver` matches one Edge major and refuses otherwise, with a message of the same shape. `geckodriver` is looser - it documents a minimum supported Firefox version and works across a range, so a Firefox suite does not break on every major bump the way a Chrome one does.
- The message also prints a binary path. Why does that matter?It names the Chrome that actually started, which is often not the one you assumed. A machine can carry a second install, or a configured browser path can point somewhere stale. Comparing that path with the version you meant to drive frequently explains the mismatch on its own.
The driver is a translator hired for one edition of the airline's seat-map manual. When the airline reprints the manual with renumbered rows, the translator refuses the job at the door rather than guess at the new numbering.
saying these in an interview costs you the question
- Reruns the suite expecting a transient startup failure
- Edits the seat-map page object although no page loaded
- Adds a longer wait before the first element lookup
- Says the Selenium library version caused the refusal
- Assumes the full four-part version must match exactly