ChromeDriver is the bridge that lets a WebDriver test send browser commands to Google Chrome. A test framework asks for actions such as opening a page, finding an element, clicking it, or reading the current URL. ChromeDriver translates those requests into Chrome control. It does not contain the browser engine and does not run a test suite by itself; a Chrome installation and WebDriver code remain separate parts of the automation.
Browser control
A test starts a ChromeDriver service and requests a new session. The session owns one controlled Chrome instance until the test quits it. WebDriver commands then target that session, which prevents one test from silently controlling an unrelated browser window. Closing a visible tab is different from ending the session because the driver process and other windows may still remain active.
ChromeDriver looks for Chrome in known installation locations. A portable, development, or custom browser location needs an explicit binary path in the Chrome options. Supplying the ChromeDriver path does not tell it where the browser lives; those are two different executables.
Version pairing
The browser and driver must speak compatible protocol versions. Chrome for Testing publishes matching Chrome and ChromeDriver builds together, which removes most guessing when the automation controls that packaged browser. A normal installed Chrome may update independently, so its driver selection follows the documented browser build components.
A mismatched pair can fail before the first page opens with a session-creation error. Repeating the test does not repair that pair. The useful check compares the actual browser binary used by the session with the actual ChromeDriver binary on the process path, not merely the versions that a package file claims to have installed.
Session options
Chrome-specific capabilities travel through ChromeOptions or the goog:chromeOptions capability. They can set command-line arguments, extensions, preferences, the browser binary, and other startup choices. These options apply when the session starts; changing the configuration object afterward does not rebuild an already running browser.
An argument needs the form that Chrome itself accepts. A malformed switch may be ignored or may stop startup, depending on the option. ChromeDriver can also use preferences for a new profile, but managed policy and operating-system controls can override a preference that works on an unmanaged test machine.
Temporary profiles
ChromeDriver creates a temporary user-data directory by default. The clean profile avoids personal cookies, extensions, and history from an everyday browser, which makes tests more repeatable. It also means that a site login present in the user’s normal Chrome profile does not appear automatically in the automated session.
A custom profile needs a user-data-dir argument. Reusing a profile that another Chrome process already owns can fail because Chrome locks the profile. The detach option can leave Chrome open after the controlling process ends, but ChromeDriver may then be unable to delete the temporary profile directory. Tests that require cleanup should quit the session explicitly instead of treating process exit as the same action.
Remote access
The driver accepts local connections by default. Remote control requires explicit allowed IP settings. Opening that service to an untrusted network gives another computer a path to start and control a browser under the service account.
The security guidance recommends a protected environment, a non-privileged account, and firewall rules around ChromeDriver and Selenium Server ports. A test host should not share sensitive personal browser data with an exposed automation service. Network reachability is therefore part of the test setup, not a convenience switch to enable without access controls.
