Selenium 4.47 Release: BiDi First, Selenium 5 Charter

Selenium 4.47 dropped on 10 August 2026, and most teams I talk to haven’t read past the version bump. That is a mistake. This release blocks Chrome DevTools Protocol (CDP) access on Firefox, hardens the WebDriver BiDi transport layer, and ships the first Selenium 5 release charter. If your regression suite still leans on CDP for network interception, performance traces, or console logs, Selenium 4.47 is an early warning sign, not a routine patch.

Table of Contents

• What Actually Shipped in Selenium 4.47
• The Big Story: Selenium 5 Gets a Release Charter
• Firefox Now Blocks CDP: The Change That Breaks Tests
• WebDriver BiDi Keeps Expanding in Selenium 4.47
• Selenium Manager and Driver Updates
• Deprecations and Bug Fixes Worth Knowing
• Selenium Grid and Kubernetes: What Changed
• An Upgrade Checklist for Selenium 4.47 (With Code)
• India Context: What Selenium 4.47 Means for Your Career
• Key Takeaways
• FAQ: Selenium 4.47 and the Road to Selenium 5

What Actually Shipped in Selenium 4.47

I read the full changelog so you don’t have to. Selenium 4.47.0 shipped on 10 August 2026, roughly a month after 4.46.0 landed on 11 July. The release is lighter on headline features than some past releases, but the items it does carry are directional: almost all of them point the project toward WebDriver BiDi as the default automation protocol.

The Selenium project now sits at 34,377 stars and 8,715 forks on GitHub. The bindings that matter to my readers (Python, JavaScript, Java, .NET) all ship 4.47.0 in lockstep, and PyPI’s selenium package and npm’s selenium-webdriver both resolve to 4.47.0 today.

Here are the four changes I think actually matter to a working SDET:

• Selenium 5 release charter is now written down, and it deprecates CDP.
• CDP access with Firefox is blocked across .NET, Python, and Ruby bindings.
• The BiDi transport layer was rebuilt to support generated BiDi modules.
• geckodriver moved to 0.37.1 and Selenium Manager got smarter about locating browsers and Electron.

Everything else in the changelog is bug fixes and build plumbing. The signal-to-noise ratio here is high, and the signal is “get off CDP, get onto BiDi.”

The Big Story: Selenium 5 Gets a Release Charter

The most important thing in this release isn’t a code change. It’s a document. Selenium 5 now has an official release charter, merged as pull request #17717 and stored under docs/plans/selenium-5.md.

I read the charter PR body in full. The headline is that the project finally pinned down what “Selenium 5” means after roughly two years of debate. At the first TLC Summit in San Francisco, the plan was to implement the BiDi API, take Selenium Manager out of beta, and deprecate CDP with big breaking changes. Last year at the Valencia summit, the scope widened to reimplementing every existing method over BiDi with a Classic fallback.

The charter closes that debate. Three decisions still need to be settled by accepted ADRs before 5.0 ships, and none of them is accepted yet:

1. The BiDi support boundary: is BiDi internal-only, or is some of the surface supported, and where does the line sit?
2. The network async/event API: the handler surface for add, remove, and clear on requests, responses, and authentication, plus how handlers behave (observe versus intercept).
3. The script and logging async/event API: the surface for pinned script execution and log handling.

Here is the detail that matters to you as a tester: the Classic-fallback mechanism, which was in the plan from day one, was removed from the 5.0 scope at the June 2025 TLC meeting. It got folded into a separate “classic-over-BiDi” migration instead. That means when Selenium 5 lands, enabling BiDi will no longer be guaranteed to preserve your existing behavior. Your Classic-mode tests will need real migration work, not a flag flip.

I treat this as a deadline, not a headline. Nobody has announced a Selenium 5 release date. But if your team runs a large Selenium suite and has not started the BiDi conversation, Selenium 4.47 is the release that should start it.

Concretely, here is what I tell every SDET I work with: inventory every CDP call in your codebase this quarter. For each one, write down which browser it targets and whether BiDi already has an equivalent. Network interception, console log capture, and performance tracing all have BiDi equivalents today. The gap is usually auth handling and a few browser-specific quirks. Knowing the size of that gap is what turns “Selenium 5 is coming” from an anxiety into a plan.

Firefox Now Blocks CDP: The Change That Breaks Tests

This is the concrete breakage in Selenium 4.47. The changelog line is unmissable: “prevent CDP access with Firefox” across the .NET, Python, and Ruby bindings (pull request #17849).

CDP, the Chrome DevTools Protocol, was never a Firefox feature. Firefox speaks a different remote debugging protocol (RDP, the Remote Debugging Protocol). Some Selenium setups had been routing CDP-style calls at Firefox anyway, and the bindings previously tolerated it. Selenium 4.47 stops tolerating it. If your suite calls CDP methods against a Firefox session, those calls now fail instead of silently misbehaving.

What does this actually look like in practice? In Python, anything under the driver.execute_cdp_cmd() path, network interception built on CDP, or console/performance capture that assumed Chromium. In JavaScript, the same applies to CDP commands sent to a Firefox WebDriver instance. If you were only ever using CDP against Chrome or Edge, you are fine. If you were using it against Firefox, this release surfaces the bug you had been living with.

Here is the specific call that breaks. If your framework has a helper like the one below and the session is Firefox, Selenium 4.47 raises an error instead of silently ignoring the mismatch:

# This worked (or limped along) before 4.47. It now fails on Firefox.
driver.execute_cdp_cmd("Network.enable", {})
driver.execute_cdp_cmd("Network.setBlockedURLs", {"urls": ["*.png"]})

That pattern is everywhere in legacy suites, usually hiding behind a method called block_requests() or capture_network(). The moment you upgrade, every one of those paths throws on Firefox.

My advice is blunt: if a test uses execute_cdp_cmd against Firefox, rip it out now and rebuild it on WebDriver BiDi. BiDi is the protocol that works across Chromium, Firefox, and WebKit. The alternative is a per-browser fork in your framework, and that fork is exactly the maintenance burden you are trying to avoid.

For a full map of what to audit when you switch a suite to BiDi, I wrote a dedicated checklist earlier: Selenium 4 BiDi Testing Checklist for QA Teams.

WebDriver BiDi Keeps Expanding in Selenium 4.47

Most of the non-trivial engineering in this release went into BiDi, and it shows.

A new transport layer for generated BiDi modules

The biggest single change is a new transport layer that will be used by generated BiDi modules (pull request #17758). In plain English: instead of hand-writing BiDi plumbing per binding, the project is moving to generating modules from the shared BiDi schema. That matters because it means the Python, Java, Ruby, and .NET bindings should drift less and ship BiDi features at roughly the same time. For a tester, less drift means fewer “works in Java but not Python” surprises.

Ruby gets Safari Preview BiDi and moves #bidi onto Driver

The Ruby binding now supports WebDriver BiDi on Safari Preview and moved the #bidi accessor onto Driver itself (pull request #17729). If your team runs cross-browser suites that include Safari, this is the first sign of a real BiDi path there. Safari has historically been the awkward one in automation, so BiDi support there is meaningful.

Smaller BiDi fixes

There is also a fix for BiDi not initializing on a RemoteWebDriver built through the builder pattern (pull request #17792), plus a lot of schema-fidelity work on types, enums, and outbound validation in Ruby. None of it is glamorous. All of it reduces the chance your BiDi session silently drops events.

Selenium Manager and Driver Updates

Selenium Manager, the Rust binary that handles driver and browser resolution, got three improvements worth noting:

• Electron driver resolution now honors --browser-version (pull request #17567). If you automate Electron apps, you can pin the driver version instead of letting Selenium Manager guess.
• Chrome and Edge are now located in known install directories (pull request #17838). This fixes the “I installed the browser in a non-standard spot and Selenium Manager can’t find it” problem.
• Linux arm64 testing was added (pull request #16045). A small step, but it signals the project is serious about arm64 as a first-class platform, which matters for anyone running tests on Apple Silicon or Graviton boxes.

On the driver side, Selenium 4.47 updates the bundled geckodriver to 0.37.1, which Mozilla released on 20 July 2026. There is also a fix to prevent an empty driver version from being cached in Selenium Manager’s metadata (pull request #17757), which had been causing a class of flaky “driver not found” failures.

Deprecations and Bug Fixes Worth Knowing

Beyond the headline changes, Selenium 4.47 removes one long-dead feature and fixes a few bugs that have bitten real suites.

The removal: deprecated FTP proxy support is now gone from the Java, JavaScript, and Ruby bindings (pull request #17846). If you were still automating a browser through an FTP proxy in 2026, this is your sign to stop. I have not met a team doing that in years, so for most people this is a no-op.

The bug fixes are more interesting, because two of them are locator bugs:

• By.className() and By.id() no longer mis-escape non-ASCII leading digits (pull request #17815). If you ever had a selector that started with a digit or a non-ASCII character and silently matched the wrong element, this is the fix.
• By.name() no longer double-formats names containing a percent sign (pull request #17888). A name with % in it was being run through String.format twice, which corrupted the selector.
• no_proxy matching was fixed so empty entries and substrings no longer bypass the proxy (pull request #17884). A security-adjacent fix: if you rely on no_proxy to keep certain hosts off the proxy, this stops a subtle data leak.
• Driver service subprocesses are now cleaned up reliably (pull request #17889), which stops orphaned chromedriver and geckodriver processes piling up on CI runners.

None of these need a migration, but if you have been chasing a flaky selector or a slow memory leak on a long-running CI machine, Selenium 4.47 is worth upgrading for these alone.

Selenium Grid and Kubernetes: What Changed

If you run Selenium Grid on Kubernetes, two changes here will save you a support ticket.

First, Dynamic Grid video recordings now go into a per-session subfolder via the SE_VIDEO_SESSION_SUBFOLDER flag (pull request #17856). Before, a long-running node could accumulate every session’s video into one directory, which made cleanup a chore and session isolation murky. The follow-up (pull request #17876) makes the per-session subfolder the default for dynamic K8s video.

Second, Dynamic Grid on Kubernetes now inherits the Node Pod’s securityContext (pull request #17860). That fixes the recurring issue where the video or log sidecar could not write to its volume because the pod and its containers disagreed on filesystem permissions.

Neither change is glamorous, but both are the kind of thing that silently breaks a distributed suite in production. I have a longer walkthrough on keeping your Grid healthy here: Selenium Grid Health Checks for Enterprise QA.

An Upgrade Checklist for Selenium 4.47 (With Code)

Here is the exact order I use when I upgrade a client suite to a new Selenium release. Run the smoke test first, then do the CDP audit, then flip the version pin.

Step 1: Smoke test the upgrade

Pin the new version and run one browser-launch test per browser you support.

pip install "selenium==4.47.0"
# or, if you manage Python with uv
uv add "selenium==4.47.0"

from selenium import webdriver

for options in (webdriver.ChromeOptions(),
                webdriver.FirefoxOptions(),
                webdriver.EdgeOptions()):
    driver = webdriver.Remote(command_executor="http://localhost:4444",
                              options=options)
    driver.get("https://example.com")
    print(driver.title)
    driver.quit()

Step 2: Audit for CDP-against-Firefox

Grep your codebase for CDP entry points, then confirm none of them run against Firefox.

rg -n "execute_cdp_cmd|cdp" --glob "*.py" --glob "*.ts" --glob "*.java"

Every hit that touches a Firefox session is a test Selenium 4.47 will now fail. Rebuild those on BiDi before you merge the upgrade.

Step 3: Verify BiDi sessions still start

If you already use BiDi, confirm a session initializes after the transport rewrite. The simplest check is to enable BiDi on Firefox and read a network event.

from selenium import webdriver
from selenium.webdriver.firefox.options import Options

options = Options()
options.enable_bidi = True
driver = webdriver.Firefox(options=options)
driver.get("https://example.com")
print(driver.title)  # if this renders, BiDi transport is healthy
driver.quit()

Step 4: Check Grid video isolation

If you run Dynamic Grid on Kubernetes, set SE_VIDEO_SESSION_SUBFOLDER=true and confirm each session’s recording lands in its own directory. This is a one-line change that stops a slow build-up of tangled video files.

For a fuller version-by-version migration template, I published the Selenium 4.46 walkthrough last month: Selenium 4.46.0 Upgrade Smoke Test for SDETs. The steps carry over to 4.47 unchanged.

India Context: What Selenium 4.47 Means for Your Career

Here is the part that matters to the audience I actually write for: QA engineers and SDETs in India and Southeast Asia, most of them mid-career and trying to move from manual testing into automation.

Selenium is still the dominant tool in the Indian service-company ecosystem. TCS, Infosys, Wipro, Cognizant, and the rest still run thousands of Selenium Java suites for banking, insurance, and healthcare clients. That is not changing in 2026. What is changing is which Selenium skills separate a mid-level automation engineer from a senior SDET.

CDP is becoming a liability. If your entire differentiator is “I know how to do network interception via execute_cdp_cmd,” Selenium 5 is going to take that away from you. The engineers I see moving into the ₹25-40 LPA senior SDET bracket are the ones who understand WebDriver BiDi, can explain why it works across Chromium, Firefox, and Safari, and can migrate a legacy CDP-based suite without breaking it.

Meanwhile, product companies and well-funded startups in Bengaluru and Hyderabad have largely moved to Playwright. If you want my honest read on that divide, I wrote it up here: Playwright vs Selenium in 2026: Which Should You Learn?. My advice doesn’t change in Selenium 4.47: learn both, but understand BiDi regardless of which framework you run, because BiDi is the shared protocol underneath both of them.

One practical way to stand out in interviews: walk in knowing the difference between CDP and BiDi, and be ready to explain why Selenium 4.47 blocks CDP on Firefox. That single question is an easy filter, and most candidates I interview still can’t answer it cleanly. If you can, you are already ahead of the crowd.

Key Takeaways

• Selenium 4.47.0 shipped 10 August 2026; it blocks CDP access on Firefox across .NET, Python, and Ruby.
• The first Selenium 5 release charter is now public, and it deprecates CDP in favor of WebDriver BiDi.
• The Classic-fallback mechanism was removed from Selenium 5.0 scope, so BiDi migration is real work, not a flag flip.
• The BiDi transport layer was rebuilt for generated modules, and Ruby gained Safari Preview BiDi support.
• geckodriver moved to 0.37.1, and Selenium Manager now locates Chrome and Edge in known install directories.
• Dynamic Grid on Kubernetes got per-session video subfolders and inherited pod securityContext.

FAQ: Selenium 4.47 and the Road to Selenium 5

Is Selenium 4.47 a breaking change?

For most teams, no. The one genuine break is CDP access on Firefox, which is now blocked. If you never ran CDP against Firefox, you can treat 4.47 as a routine minor upgrade. If you did, those tests will fail until you move them to WebDriver BiDi.

Do I need to move to WebDriver BiDi right now?

Not immediately, but soon. BiDi is the protocol Selenium 5 is built around, and CDP is being deprecated. If your suite is stable on Classic mode, keep it stable. But start the BiDi migration conversation now, because the Classic fallback that would have made the Selenium 5 transition painless was removed from the 5.0 scope.

Will Selenium Manager break my CI pipeline?

Unlikely. The changes make it more reliable: it now honors --browser-version for Electron, finds Chrome and Edge in standard install locations, and no longer caches empty driver versions. If anything, you should see fewer “driver not found” failures after upgrading.

Does this affect Selenium Grid users?

Only if you run Dynamic Grid on Kubernetes. The per-session video subfolder and inherited securityContext are K8s-specific. Standalone and Hub/Node users are unaffected.

When is Selenium 5 coming out?

No date has been announced. The charter has to be finalized, three ADRs still need to be accepted, and the network and script async APIs need to be built out. Treat it as “next major release, timeline unknown” and use the time to audit your CDP usage.