--- title: "Review an install" description: "Review requirements, permissions and policy changes before installing." canonical_url: "https://docs.oz0.ai/build/plugins/install/review" --- # Review an install > Review requirements, permissions and policy changes before installing. For: tenant administrators and plugin authors. Review requirements, permissions and policy changes before installing. ## What the install shows first Enter a source in the console's Install dialog to inspect the plugin before installing it. The CLI prints the same Needs, May do and Reaches sections. ### Needs This section lists values to supply and permissions to grant: - Secrets by name, with a masked field for each value. - Settings in the same typed form as the [Configure tab](https://docs.oz0.ai/build/plugins/configure), using each required setting's example as its hint. - Connections declared by the plugin and model aliases its agents request that the tenant does not have. - Access to [other plugins](https://docs.oz0.ai/build/plugins/install/grants#plugins-that-use-other-plugins), records it fills or reads, results it reads from selected plugins ([the results grant](https://docs.oz0.ai/improve/evidence-for-agents#the-grant)), and model calls made in the calling job's name. The dialog shows whether a secret exists only with `secrets.read`, a setting's value only with `settings.read`, and a connection's state only with `connections.manage`. Without the relevant permission, it says the value or state is not visible to you. ### May do The dialog groups functions as Read, Write, Sends out, Destructive or Unknown. Each function shows Allow, Ask or Refuse and the reason for that default, such as "read-only", "the author marked it destructive", "the plugin asks before it writes", or "your tenant asks before every destructive call". The default is the [tool policy](https://docs.oz0.ai/govern/tool-policy) decision that would apply after installation. The engine checks an existing tenant rule first, then the plugin's suggested policy, then the function's declarations. Rules installed from the suggested policy keep the plugin attribution and reason. Use a function or group switch to change its default before installation. A function with `requires_approval` always shows "Ask, set by the plugin" and has no switch. Judge appears on each switch but is unavailable until 1.1. A suggested judge uses Ask until then and shows its question. A capability plugin also lists other plugins' functions that its agents are granted. These switches apply only to its own agents through a [rule by caller](https://docs.oz0.ai/govern/tool-policy/conditions#rules-by-caller). A policy plugin lists its hooks, matching events, possible decisions and timeouts. Functions come from the version's measured `tools.listing.json`. A tool without a measured listing says "its functions show once a node lists them". Until then its calls ask a person. ### Reaches This section lists hosts that plugin processes and remote tools may contact, events, flows and chat channels that start jobs, and secret names. It never shows secret values. A host that the tenant does not yet permit is marked for a tenant admin to approve. A host that serves files anyone can publish is marked with that reason too; that finding does not refuse installation. ### Apply the install choices The Install button applies the choices in order: install with the displayed grants and any aliases you mapped with model-management permission, then settings, secrets and the switches as one tool-policy change. A stricter switch applies immediately. A looser switch requires a reason and, when four eyes are enabled, another admin's approval. Plugin configuration always requires another admin to approve a loosening. These install switches use the function-policy path, while Configure uses the configuration path; see [the two paths](https://docs.oz0.ai/govern/tool-policy/plugin-functions#two-paths-for-a-plugins-functions). The dialog asks for a reason as soon as a switch changes. It reports completed and remaining steps, with the command and permission needed for each remaining step (`settings.write`, `secrets.write`, `governance.write`), so another person can finish the setup. If an unapproved host makes the install wait, there is no installed plugin to configure yet. The dialog stays open and lists all chosen steps as remaining. Approval comes first (`oz0 change approve`, `changes.review`), followed by aliases, settings, secrets and switches. The dialog does not keep the secret values; supply them after approval. ### Install from a terminal or script `plugin install` and `plugin update` ask once when stdin, stdout and stderr are all terminals and `--json` is absent. They print the three sections, then ask whether to install and grant what was shown. In other contexts, including CI or captured output, the commands behave as `--yes` and do not ask. `OZ0_YES=1` does the same for a script run in a terminal. They take the defaults and grant only what the explicit `--accept-uses`, `--accept-provides`, `--accept-reads` and `--accept-model` arguments name. They print the three sections after installation; JSON output includes them in `screen`. ```bash [Terminal] oz0 plugin install https://github.com/acme/oz-desk --yes oz0 plugin install https://github.com/acme/oz-desk --policy desk.post=refuse --policy write=ask --reason "posts are by people" oz0 plugin install https://github.com/acme/oz-desk --config desk.yaml --reason "the desk's setup" ``` Repeat `--policy =` to change defaults. A switch needs `--reason` or `$OZ0_REASON`, checked before installation starts. Remaining steps are printed with their command and permission, and the command exits non-zero. `--config ` reads a file written by `oz0 plugin config export`. It applies settings and `tools:` after installation, and files models, budgets, egress and schedules as a [configuration change](https://docs.oz0.ai/build/plugins/configure). A loosening in `tools:` needs another admin only with four eyes enabled; a loosening in the rest always does. ### Review defaults on update Existing tenant switches remain as rules naming functions. New functions are marked new. A function that becomes more consequential, from Read to Write, Write to Destructive, or newly Sends out, gets a rule restoring its stricter default. You can keep the old choice by switching it back with a reason. The engine compares types during installation when a measured listing is available, or when a node first lists the functions. A type already compared at installation is not reset again when a node lists it, so a choice made between those events remains. The exception is a type more consequential than both the previous version and the measured listing reported. A listing that understates the previous version's type does not weaken that comparison. The page reserves space for plugin-view notes but currently shows none there. ### What its agents combine At the end of May do, the screen names each agent that combines private data, outside input and sending out while a sending function runs without asking: the functions or starts behind each of the three, and the sending functions that would close it. Its one action switches those to Ask on the screen; the flag clears as soon as none is left on Allow, and the Install button applies the switches with the rest. The CLI prints the same block with the command that closes each function (`--policy =ask` on the install). A flag never refuses the install: you decide. Flags show combinations worth a second look. No flag does not mean an agent is safe. See [What an agent combines](https://docs.oz0.ai/build/parts/what-an-agent-combines). The screen also lists the pairs of the tenant's [duty rules](https://docs.oz0.ai/govern/tool-policy/duties#duties) an agent would hold. A pair the tenant marks refuse refuses the install, naming the rule; a flagged one is a warning, and the install goes ahead. The same holds for `oz0 plugin grant --accept-uses`, which grants an installed plugin's uses later. ## Sitemap See the full [sitemap](https://docs.oz0.ai/sitemap.md) for all pages.