In Appium, why must you pass --use-plugins at server start when --use-drivers is optional?

## Installing an extension is not activating it Appium's extension system has two distinct steps, and conflating them is the whole of this question. **Installation** is a state of an `APPIUM_HOME` directory: `appium driver install uiautomator2` or `appium plugin install images` fetches a package into that home and records it in the `extensions.yaml` manifest. **Activation** is a property of one server process: which of the installed extensions that process loads when it starts. `--use-drivers` and `--use-plugins` are the activation controls, and their defaults are deliberately asymmetric. - Every installed **driver** is activated by default; `--use-drivers` exists only to narrow that set. - No installed **plugin** is activated by default; `--use-plugins` exists to opt in, by name or with the value `all`. ## Why the two defaults differ The asymmetry follows from what each extension kind does to a session. A driver is *selected*, not *applied*. It participates only when a session request's capabilities match what it claims, so a host with the UiAutomator2 driver (**Android**) and the XCUITest driver (**Apple platforms**) both installed can serve either kind of session, and neither driver affects the other's traffic. Leaving them all active is therefore free of behavioural surprise; the costs are startup time and memory, not correctness. A plugin is *applied*. It sits in the command path and may intercept, replace or add commands for **every** session the server handles, whichever driver answers. An extension with that reach must not switch itself on merely because somebody installed it once on a machine other people also use. Opt-in is the safe default, and it explains the symptom that brings people to this question: a freshly installed plugin that appears to do nothing is installed and inactive. ## Writing the flags - `appium --use-plugins=images` activates one plugin for this process. - `appium --use-plugins=all` activates every plugin the home holds. - `appium --use-drivers=uiautomator2` restricts the process to the **Android** UiAutomator2 driver, so an Apple-platform session request will not match on that host. - Both flags take a comma-separated list and name extensions exactly as the install and list subcommands do. Because activation is per process, two servers started from the same `APPIUM_HOME` can carry different extension sets. That is a legitimate technique when one host serves two suites with different plugin needs, and a confusing one when it happens by accident. ## The failures this asymmetry produces | Symptom | Usual cause | |---|---| | A plugin is installed but nothing it adds appears | the process started without `--use-plugins` naming it | | A plugin works on one host and not another | the flag lives in one start command and not the other | | A session that used to match now finds no driver | `--use-drivers` was added and left the needed driver out | | Two servers behave differently from one install | activation is per process even though the manifest is shared | Triage in three steps: 1. Confirm what the home holds: `appium driver list --installed` and `appium plugin list --installed`. 2. Confirm what the process was told to load: read the command that started the server, not your install history. 3. Confirm which server the client actually reached, since activation travels with the process and the manifest does not. ## Treat the start command as configuration The practical discipline is to keep the activation flags with whatever starts the server rather than in somebody's shell history. An install is a one-off act on a directory and leaves evidence in the manifest; activation is repeated on every start and leaves no evidence on the machine at all. That difference is why the plugin half of this question bites hardest: a driver that is not active fails loudly, because sessions stop matching, while a plugin that is not active fails silently - the commands it would have added are simply not there. So a suite that depends on a plugin's added commands should assert that dependency rather than assume it. For a **library loan-renewal** suite whose checks lean on a plugin, an inactive plugin is the difference between a red test and a green one that verified nothing, and the flag deciding which of those you get is on the start command, not in the install log.