The Boundary Is Part of the Capability
Agent Reach treats authentication and installation as part of a capability’s behavior, not as invisible setup. This chapter follows the lifecycle from user consent to local configuration, browser or service state, direct upstream use, verification, and cleanup. The practical judgment is whether a route is worth enabling in a particular environment without confusing convenience with permission, or local storage with safety.
Consent Decides What the Installer May Change
A one-line installation request can conceal several different kinds of action. Installing the Agent Reach package changes one Python environment. Installing an upstream CLI changes the machine’s available tools. Configuring an MCP service changes how an agent can reach an external process. Registering a skill changes what an agent may discover in future conversations. These are related transitions, but they do not have the same scope or reversibility.
The project draws that line with its install modes. The default agent-reach install --env=auto is a check-only operation. The compatibility --safe mode keeps that behavior, and --dry-run previews what a system installation would do. The --system flag is the explicit boundary for installing external dependencies, configuring services, and writing skill files. This is more than a user-interface nicety. It ensures that discovering a missing capability does not automatically become authorization to modify the host.
The distinction also improves diagnosis. In a read-only pass, Agent Reach can inspect whether Node.js, the GitHub CLI, mcporter, and other prerequisites are present, then report what would be needed. A user can approve only the channels that matter. The installer’s baseline is intentionally different from its optional set: lower-friction routes can be checked or activated first, while login-backed or environment-specific channels are named separately. This prevents an agent from turning a broad platform list into a broad permission request.
The lifecycle has a clear ownership pattern. The installer can detect a local or server-like environment and propose a route. The user decides whether system changes are permitted and which optional capabilities to add. The package manager creates or updates the external tools. Agent Reach records selected configuration and, when explicitly allowed, registers the agent skill. Doctor later observes the result. No single step proves that the final platform operation will succeed.
That last qualification matters because --system is not a safety bypass. It is a consent gate, not a guarantee about the packages being installed or the network they will contact. The installation guide still tells the agent not to use sudo without explicit approval, not to modify unrelated system files, not to disable security controls, and not to install packages outside the documented scope. A user can authorize a system-level action while still limiting its purpose. Good capability acquisition preserves both decisions.
There is also a persistence question. A dry run leaves no intended change. A check-only install may leave the existing host untouched. An approved system installation can persist external binaries, an MCP entry, or a skill file. A user-provided key or cookie can persist under the private configuration directory.