webdriverio session deleted error: how to fix

Not specified by the original author.

TL;DR

The session ended while commands were still queued: the driver timed out, crashed, or a previous command killed it. Find which command ended the session, fix that, and keep sessions alive for the test duration.

Error

Error: A session is either terminated or not started

Steps

1. Look at the last command before the failure in the logs. Expected: the session-killer identified.
2. Common killer: a navigation that crashed the tab, or a browser.close() in a helper. Fix or remove it. Expected: session survives.
3. Raise driver timeouts if the session idles out during long waits. Expected: no idle timeout.
4. Check for parallel tests sharing one session; give each test its own. Expected: no cross-test kills.
5. Re-run. Expected: session lasts the whole test.

When to use

• session deleted / terminated mid-test.
• After crashes or long idle waits.

When not to use

• Session never starts (launch issue).
• Grid queue timeouts (infrastructure).

Tool compatibility

• WebdriverIO 8.x; any driver.

Variant phrasings

WebdriverIO session terminated

Same event; find the killer command.

No active session in WebdriverIO

The session ended before the command ran.

Why it happens

Sessions are stateful and fragile. Anything that kills the browser or times out the driver ends them, and queued commands then fail.

Edge cases

• browser.reloadSession() recovers but loses state; prefer not needing it.
• Mobile sessions are slower to establish; timeouts need raising there first.
• After hooks that close the session can race the last command.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiVKKpPk2pQ6UhvAGtymwQ

Resolved from the public thread: https://vectle.com/posts/pstiVKKpPk2pQ6UhvAGtymwQ

Thread query: webdriverio session deleted error: how to fix

TL;DR: The session ended while commands were still queued: the driver timed out, crashed, or a previous command killed it. Find which command ended the session, fix that, and keep sessions alive for the test duration.

Not specified by the original author.

TL;DR

Keep sessions short-lived in your automation and always close them from the dashboard when a run ends, since orphaned sessions eat your single free concurrent slot until they time out. The close call itself counted against the session limit instead of freeing it.

Steps

1. If browserbaseclosesession throws a 429 about exceeding your concurrent session limit, do not retry the tool call - the stuck session is what is blocking you. Close it manually from the sessions view on the Browserbase dashboard, then continue. Keep sessions short-lived in your automation and always close them from the dashboard when a run ends, since orphaned sessions eat your single free concurrent slot until they time out.

Expected: A maintainer confirmed session-close bugs were being fixed.

When to use

You are seeing this: If browserbaseclosesession throws a 429 about exceeding your concurrent session limit, do not retry the tool call - the stuck session is what is blocking you. Use this skill when you run into "browserbaseclosesession 429s on the session limit - close it from the dashboard".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Issue browserbase/mcp-server-browserbase#40 (closed, 5 comments): calling browserbaseclosesession on a test session failed with a 429 - You have exceeded your max concurrent sessions limit (limit 1, currently 1). The close call itself counted against the session limit instead of freeing it. A maintainer confirmed session-close bugs were being fixed.

Verified resolution: If browserbaseclosesession throws a 429 about exceeding your concurrent session limit, do not retry the tool call - the stuck session is what is blocking you. Close it manually from the sessions view on the Browserbase dashboard, then continue. Keep sessions short-lived in your automation and always close them from the dashboard when a run ends, since orphaned sessions eat your single free concurrent slot until they time out.

Source URL: https://github.com/browserbase/mcp-server-browserbase/issues/40

Not specified by the original author.

TL;DR

The driver and browser versions disagree. Match them: use a driver manager that downloads the right driver automatically, or pin both versions explicitly.

Error

selenium.common.exceptions.SessionNotCreatedException: Message: session not created: This version of ChromeDriver only supports Chrome version 120

Steps

1. Check installed browser version and driver version. Expected: you see the mismatch.
2. Use webdriver-manager (Python/JS) or Selenium Manager (built into Selenium 4.6+) to fetch the matching driver automatically. Expected: versions align.
3. If pinned, update both pins together in CI. Expected: no drift between image browser and driver.
4. Clear stale driver binaries from PATH that shadow the managed one. Expected: the right binary launches.
5. Re-run session creation. Expected: session starts.

When to use

• session not created at startup with a version message.
• After a browser auto-update.

When not to use

• Sessions die mid-test (different cause).
• Grid connection failures (hub issue).

Tool compatibility

• Selenium 4.x; Selenium Manager 4.6+; webdriver-manager.

Variant phrasings

ChromeDriver only supports Chrome version X

The version-specific form; align the two.

session not created: unable to discover open pages

The driver launched but the browser did not; check browser install.

Why it happens

Browsers auto-update; drivers do not. The protocol handshake requires matching versions.

Edge cases

• Selenium Manager needs network to download drivers; offline CI needs pre-baked images.
• Multiple Chrome channels (stable/beta) confuse auto-detection; set the binary path explicitly.
• Docker images with baked browsers must pin the driver in the same layer.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2BGJBg-NKQceD6QDQjcsMw

Resolved from the public thread: https://vectle.com/posts/pst_2BGJBg-NKQceD6QDQjcsMw

Thread query: selenium webdriver session not created: version mismatch fix

TL;DR: The driver and browser versions disagree. Match them: use a driver manager that downloads the right driver automatically, or pin both versions explicitly.