When your runner attaches to a browser already running remotely, what does it stop having to install?

## What is actually on the runner A test runner that drives a browser on its own machine has to carry that browser: the engine build, and whatever else has to stay lined up with it. That is usually the largest and most fragile part of the runner's setup. It has to be installed, it has to be the right build, and it has to be reinstalled whenever the image is rebuilt. When the runner instead **attaches to an engine that is already running somewhere else**, that whole burden leaves. There is nothing to download, because nothing is being started -- the engine was running before your connection existed, and your connection joins it rather than causing it. ## Why there is nothing to fetch The distinction worth holding onto is between *starting* a browser and *joining* one. - Starting a browser means something, somewhere, has to have the build. If that something is your runner, the build is the runner's problem. - Joining a browser means the build is already where it needs to be. Your side supplies a way to talk to it and nothing else. An attachment is the second case taken to its conclusion: no engine build on the runner, no installation step in the setup, and no version of an engine for the runner's image to pin. ## What does not leave This is the half candidates skip, and it is where a good answer separates itself. - **The client library.** Your tests still call into something, and that something is still a dependency you install and update. - **The endpoint address.** It is configuration, it has to reach the runner, and on a hosted service it commonly carries an account credential -- which makes it a secret in its own right rather than a harmless setting. - **Your own test dependencies.** Fixtures, seed data, files the tests upload, the test framework itself: none of that moves anywhere. - **The agreement between the two ends.** The client library and the far side still have to speak a protocol they both understand, and your tests still have to be written for whatever the engine actually is. The one-line version: attaching moves the **platform** off your runner. It does not move the **harness**. ## The engine's identity was settled before you connected Because there is no new-session request in this shape, there is no moment at which your side describes the browser it wants and the far side matches it. The engine you reach was already running, with whatever build and whatever platform it had, before your connection existed. You choose which engine by choosing where to connect, not by describing what you want. The practical consequence for a junior is small but real: when someone asks "which browser did that run use?", the answer does not come from your configuration in the way it would when a session is created to order. It comes from what was running on the other end. ## A concrete picture A warehouse pick-and-pack console suite runs in CI. In its first form the pipeline installs a browser engine into the runner image, and a good share of every build is spent putting it there and keeping it current. Moved to an attachment against a hosted engine, the install step disappears entirely and the image gets noticeably thinner. What survives the move is everything the suite itself needs: the client library, the address (kept as a secret, because of what it carries), the fixtures that seed the console's stock data, and the test code. A reviewer looking at the change should see one dependency leave and none of the others pretend to. ## What to say in an interview Say the mechanism, then say the limit: 1. The browser is already running on the far side, so the runner installs no engine build and starts no browser. 2. The runner still needs the client library, the address and the suite's own dependencies. 3. The engine's identity was fixed before the connection, so it is chosen by where you connect rather than by what you request. That order matters. Leading with "the runner does not need anything" is the answer an interviewer is listening for as a mistake, because it confuses removing the platform with removing everything.