Introduction

On macOS Catalina, Gatekeeper can block chromedriver with a message saying the developer cannot be verified. When that happens, Selenium usually fails to launch Chrome even though the test code is otherwise correct. The root issue is normally macOS trust enforcement on the downloaded driver binary, not a bug in Selenium itself.

Why Catalina Blocks ChromeDriver

Catalina applies stricter checks to downloaded executables. If the file has a quarantine attribute, macOS may refuse to execute it until the user explicitly trusts it.

That means a perfectly valid WebDriver setup can still fail at the operating-system level.

A quick way to inspect the binary is:

xattr -l /usr/local/bin/chromedriver

If you see com.apple.quarantine, Gatekeeper is one of the first things to investigate.

This problem became common on Catalina because many browser drivers were downloaded manually from the internet, then executed by automation tools without any Finder-based approval step.

Verify Chrome and ChromeDriver Versions First

Before changing macOS security metadata, make sure the Chrome browser and ChromeDriver versions are compatible. A version mismatch can look like a launch failure even when the binary is trusted.

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version
/usr/local/bin/chromedriver --version

On newer Homebrew installations, the driver path may instead be:

/opt/homebrew/bin/chromedriver --version

Major-version mismatches are a separate issue from Gatekeeper, so it is worth ruling them out early.

Remove Quarantine from the Trusted Binary Only

If the driver came from a trusted source, the common targeted fix is to remove the quarantine attribute from that binary only.

xattr -d com.apple.quarantine /usr/local/bin/chromedriver
chmod +x /usr/local/bin/chromedriver
/usr/local/bin/chromedriver --version

This is much better than disabling Gatekeeper globally. The goal is to trust one specific file after you have verified where it came from.

If xattr -d says the attribute does not exist, the failure may instead be version mismatch, wrong driver path, or another permission problem.

Finder and System Settings Approval Path

If command-line attribute removal is not appropriate in your environment, macOS also allows a manual approval flow.

A common Catalina-era path was:

1. try launching the binary once so macOS records the block
2. open the Security and Privacy panel
3. allow execution of the blocked item
4. retry the Selenium launch

Another option is to control-click the file in Finder and choose Open, which can register trust for that specific binary.

This is slower than the shell approach, but it is useful on machines with stricter administrative controls.

Confirm the Driver Path Selenium Is Actually Using

A frequent mistake is fixing one chromedriver file while Selenium points to another copy on disk.

Python example:

1from selenium import webdriver
2from selenium.webdriver.chrome.service import Service
3from selenium.webdriver.chrome.options import Options
4
5service = Service("/usr/local/bin/chromedriver")
6options = Options()
7options.add_argument("--headless=new")
8
9driver = webdriver.Chrome(service=service, options=options)
10try:
11    driver.get("https://example.com")
12    print(driver.title)
13finally:
14    driver.quit()

Java example:

1import org.openqa.selenium.WebDriver;
2import org.openqa.selenium.chrome.ChromeDriver;
3import org.openqa.selenium.chrome.ChromeOptions;
4
5public class SmokeTest {
6    public static void main(String[] args) {
7        System.setProperty("webdriver.chrome.driver", "/usr/local/bin/chromedriver");
8
9        ChromeOptions options = new ChromeOptions();
10        options.addArguments("--headless=new");
11
12        WebDriver driver = new ChromeDriver(options);
13        try {
14            driver.get("https://example.com");
15            System.out.println(driver.getTitle());
16        } finally {
17            driver.quit();
18        }
19    }
20}

If the path in code does not match the path you fixed, the trust change will appear to do nothing.

Safer Team Workflow

If multiple developers hit this on macOS machines, treat it as an onboarding problem rather than an ad hoc laptop problem.

A sane team process is:

• install ChromeDriver from a trusted source
• verify browser and driver version compatibility
• remove quarantine only on the exact driver path in use
• run a tiny smoke test before trying the full suite

That keeps the fix narrow and repeatable.

Common Pitfalls

One common mistake is removing quarantine from one file while the automation framework uses a different chromedriver binary elsewhere in PATH.

Another mistake is assuming every launch failure is a Catalina verification issue. Chrome and ChromeDriver version mismatch can produce similar symptoms.

Developers also sometimes disable Gatekeeper globally to fix one binary. That is an unnecessarily broad security change.

Finally, always verify the source of the driver before trusting it. The security prompt is a signal to check provenance, not just an obstacle to suppress.

Summary

• Catalina often blocks downloaded chromedriver binaries because of Gatekeeper quarantine.
• Check for com.apple.quarantine before assuming Selenium is broken.
• Verify Chrome and ChromeDriver versions match before changing security metadata.
• Remove quarantine only from the trusted driver binary you are actually using.
• Confirm the exact driver path in your Selenium configuration with a minimal smoke test.