Where does Selenium Manager store the drivers it downloads, and does every Selenium 4 run download again?
answer
- Downloading every run would be intolerable
- A folder under the user's home
- Checked before the network is
- Versioned sub-folders, no expiry
- Default ~/.cache/selenium, moved by SE_CACHE_PATH
basics
~20 sIn a per-user cache folder, by default ~/.cache/selenium, and no. Selenium 4's Selenium Manager reuses a matching cached driver on later runs and downloads only when the cache has no suitable copy. SE_CACHE_PATH moves the folder.
solid answer
~40 sIn Selenium 4, Selenium Manager keeps every driver it fetches in a local **driver cache**, `~/.cache/selenium` by default, laid out in versioned sub-folders it creates itself. Resolution checks that cache before it checks the network, so only the first run on a machine — or a run that needs a driver the cache does not hold — pays for a download; every run after that is a file lookup measured in milliseconds. `SE_CACHE_PATH` relocates the folder, which matters when the account running the bank statement-download suite cannot write to its own home directory. Deleting the folder is the blunt reset: the next run simply resolves and downloads again. Nothing expires the cache on a timer, and nothing cleans it up when a test finishes.
go deeper
Remember that downloaded drivers are kept in a cache folder under your home directory and reused, so only the first run pays for a download. Knowing the default path is a bonus.
Explain the ordering — cache first, network second — and what SE_CACHE_PATH is for. Be able to say what deleting the folder does and that nothing expires entries on its own.
Recognise the cache as a diagnostic surface: per-user ownership, write permissions on the home directory, and whether a given run resolved from disk or the network explain most machine-specific resolution failures.
Decide how driver provenance is handled across many machines: whether every host resolves and caches for itself, or drivers are provisioned deliberately, and who is accountable when the two answers disagree.
## Why there is a cache at all **Selenium Manager**, the binary bundled in the Selenium 4 client since **4.6**, exists so a test can construct a driver without anybody having placed an executable first. If that convenience meant a fresh download before every session, the bank statement-download suite would be slower and far more fragile than the manual setup it replaced. The **driver cache** is what makes automatic resolution cheap enough to be the default. The rule is simple: **the cache is checked before the network**. A download is what happens when the cache cannot answer, not what happens on every run. ## Where it lives - The default location is a **per-user folder**, `~/.cache/selenium`, resolved from the home directory of whichever account runs the test. - Inside it, drivers sit in sub-folders keyed by driver and version, a layout Selenium Manager creates and manages itself. - Being per-user matters: two accounts on the same machine keep two caches, and a service account with an unusual or read-only home directory has nowhere to write one. - `SE_CACHE_PATH` (matching the binary's `--cache-path` flag) moves the folder anywhere the running account can write. - Nothing in Selenium removes entries from it. It grows as new driver versions are resolved and stays until something outside Selenium deletes it. ## First run versus every run after | | First run on a machine | A later run, same machine | |---|---|---| | Browser detection | Yes | Yes | | Cache lookup | Miss | Hit | | Network needed | Yes, to download | No | | Typical cost | A download | Milliseconds | | What is written | A new versioned folder | Nothing | That table is the whole answer to the interview question. The cost profile of automatic resolution is *one* download per driver version per cache, not one per run and certainly not one per test. ## Reading, moving and resetting it 1. **Look at it.** The folder is ordinary files; listing it tells you which driver versions the machine has already resolved. 2. **Move it** with `SE_CACHE_PATH` when the home directory is unwritable, ephemeral, or shared in a way you do not control. 3. **Reset it** by deleting the folder. There is no expiry timer and no automatic pruning, so deletion is the reset, and the next run re-resolves from scratch. 4. **Prove which happened** by running the bundled binary with `--debug`, which reports whether the path it returned came from the cache or from a download. ## Where the cache surprises people - A suite that is fast for one engineer and slow for another usually differs only in cache state, not in code. - A permission error on `~/.cache/selenium` presents as a driver-resolution failure rather than as the file-system problem it is; relocating with `SE_CACHE_PATH` fixes it. - Because the cache is per-user, running the suite under a different account is enough to trigger a full re-resolution. - Deleting the cache to "clean up" costs the next run a download; on a machine with no network route out it costs the next run entirely. - `SE_OFFLINE` and the cache are complementary, not alternatives: offline mode forbids the download, and the cache is what lets resolution still succeed. - A machine that has resolved several browser versions over time accumulates several driver versions side by side; that is expected, and old entries are simply never consulted again. ## Why a junior is asked this at all The question looks like trivia about a folder path, but it is really a check on whether a candidate has understood that automatic resolution has a **cost profile**. A candidate who thinks every session downloads a driver will reach for the wrong fixes: they will blame the network for a slow suite, propose committing a driver into the repository, or argue that automatic resolution is too risky to use. A candidate who knows the cache exists reasons correctly about all three. It is also the first place a test author meets the idea that Selenium keeps state **outside the project**. Nothing about the bank statement-download suite's source tree explains why it runs instantly on one machine and pauses on another, and being able to point at a per-user cache folder as the explanation is the whole skill being probed. ## What the cache is not The cache is a resolution accelerator, nothing more. It does not version your test suite, it is not an artefact your build produces, and it holds no session state — once a driver path has been returned, the cache plays no further part in the run. Treat it as a local convenience whose contents can always be rebuilt by resolving again, and it will never be a source of mystery.
- How would you force Selenium Manager to resolve a driver from scratch?Delete the cache folder, `~/.cache/selenium` unless `SE_CACHE_PATH` has moved it. Nothing expires entries on a timer and nothing prunes them automatically, so removing the folder is the reset. The next run detects the browser and downloads again, then repopulates the cache.
- The suite fails to resolve a driver only when it runs under a service account. What would you check first?Whether that account can write to its own `~/.cache/selenium`. The cache is per-user, so a locked-down or read-only home directory surfaces as a driver-resolution failure rather than a permissions error. Pointing `SE_CACHE_PATH` at a writable folder normally settles it.
It behaves like a toolbox drawer rather than a delivery service: the first job sends someone out for the tool, and every job afterwards just opens the drawer.
saying these in an interview costs you the question
- Says a driver is downloaded before every session
- Thinks the cache lives in the project directory
- Believes cached drivers expire automatically after some period
- Cannot name the environment variable that relocates the cache
- Assumes one cache is shared by every account on the machine