Configure an installed plugin

For: tenant administrators and plugin authors.

Open a plugin on the console's Plugins page and select Configure to change its settings for your tenant. The tab changes tenant configuration around the plugin. It preserves the plugin's files, prompts and code, whose signature, version pins and evals depend on those files staying intact.

Reading the tab takes settings.read; the egress list shows with governance.read too, and a save or a file that names an egress list, even an unchanged one, takes governance.read as well.

Settings

A setting appears with its label, its group and its help: what it is for, its default, and its bounds, such as "From 1 to 50". A required setting is marked, its example is the field's hint, and it cannot be saved empty: the plugin's nodes do not start it until it has a value. Use the default clears a value.

A value is checked as you type (a whole number, a number, a duration such as 30s, a URL, one of a list) and again by the server, which also refuses a value that carries one of the tenant's secrets. That last check runs only for someone who may change the setting.

This tab is a setting's one home when one plugin reads it. Admin › Settings › Plugin settings lists every setting the tenant has, and shows each one plugin reads as it is, with a link here; a setting no one plugin reads (several plugins read it, or none any more) is set there.

When an install warns that a required setting is not set, Fill in its settings opens this form.

Tools

Each function shows what the tenant's tool policy does with its calls now, and why: the author marked it read-only, it sends data out, your tenant asks before every destructive call. Switch one function, or a whole group at once. A switch writes ordinary tool-policy rules naming the function, placed exactly as oz0 plugin policy <plugin> --set places them: just before the rule that decided the function for every caller, so rules for some callers or some arguments still win for those calls.

It is saved as part of the plugin's configuration, though, so a switch that loosens waits for another admin here whatever the tenant's four eyes say, where oz0 plugin policy --set and the install screen wait for one only with four eyes on. A function the plugin itself asks approval for (its requires_approval) shows Ask, set by the plugin and has no switch.

What its agents combine

Above the groups, the tab names each of the plugin's agents that combines private data, outside input and sending out while a sending function runs without asking, with the functions behind each and the ones that would close it. Switch them to Ask moves the plugin's own closing functions on the tab, and the flag clears as soon as none is left on Allow; save as usual. A function no node has listed yet has no switch here, and another plugin's function is switched for this plugin's agents only: for those the tab gives the oz0 plugin policy command.

Flags show combinations worth a second look. No flag does not mean an agent is safe. See What an agent combines.

Below it, Duty pairs lists each pair of the tenant's duty rules one of the plugin's agents holds, with the functions on each side. A switch that would let an agent hold a pair the tenant marks refuse is refused when the configuration is saved.

Skills

Each agent's skills of the plugin, with what your tenant's jobs show of them over the last 30 days: how many of the agent's jobs on the installed version read each one, and what its line costs in the agent's start-up index (an estimate of the text). An agent whose harness reads its skills folder itself says not measured: its reads leave no trace. A skill its author marked as read seldom (metadata: {oz0-usage: rare} in its SKILL.md) says so.

Hide for this tenant leaves a skill out of that agent's index, its sessions' skills and folders, and its reads, in your tenant only. It is how you narrow a plugin you did not write: the plugin is signed and pinned, so its files stay as they are. A hidden skill frees its room in the agent's start-up budget, so a skill that was left out for lack of room comes back. Hide skills on another publisher's plugin; for your own plugin, change its files with a reviewed change instead (see Skills no job reads).

• Try it first. Before you save, Try it first runs the plugin's evals with the skill withheld from that agent (a comparison of a changed agent), and the change request links it. The save shows each linked comparison's verdict and warns when the evals did worse without the skill, or could not tell.
• Across updates. A skill is hidden by its name, so it stays hidden when the plugin updates. If an update changes it, or renames it away, a finding asks you to look again; keep it hidden, or show it. A skill that is new in an update shows as usual.
• What it says. The plugin then shows "skills narrowed by the tenant" here, in oz0 plugin show and on its agents' cards, after "verified" for a verified plugin, which stays verified: what "verified" means is about the plugin's own files, which are untouched. Another publisher's plugin shows only the narrowing.

A hidden skill reaches the plugin's nodes with its settings, so their runtime restarts with it, as for a changed setting. Each job reads the hidden skills once, when it starts, and keeps them for its whole run, so a job resumed after the restart decides as it did before:

• Jobs that start after the restart leave the skill out of the agent's index, its sessions' folders and its reads.
• A job that started before (or on a node whose runtime has not restarted yet) runs with the skills it started with, and may still read the hidden one. The read runs and the audit log records it as skill.hidden_read. The same holds when you show a skill again: jobs already running keep it hidden until they end.
• A node whose runtime predates hiding does not leave hidden skills out at all, so the edge refuses its reads of them, and the job that asked fails with a reason that names the hide. Update the node.

A hide narrows what an agent's context carries. It is not a security control: the skill's files are the plugin's own, and they stay on the node.

Agent changes

The plugin's change budget: at most 3 changesets that agents propose or apply to it in 7 days, and none for 72 hours after a rollback of it, unless you change them here. The section shows what counts against the budget now, a running cooldown and what started it, whether approvals of the plugin's changes look rubber-stamped (the budget is then at its floor, one changeset waiting at a time), the open change_budget finding, and the latest counted changesets with their jobs, agents and outcomes.

Allowing more, counting over a shorter period or shortening the cooldown is listed first in the diff as a loosening: it takes a reason, and another admin approves it.

Rollouts

A new version of the plugin rolls out to canary nodes first, and each step is judged on five quality signals as well as on its health and its failed jobs. This section sets each signal's threshold, in points (0.1 is 10 points worse than the installed version), or turns it off, and the floor of jobs below which a signal decides nothing. The defaults are 0.1 for each and 10 jobs.

Widening a threshold, turning a signal off or raising the floor loosens a governance control: the change request needs a reason and another admin. A rollout's own --quality-* flags may only make it stricter.

Saving is a change request

Save shows everything the save changes first, every loosening at the top, then files it as one change request. Nothing changes until a tenant admin approves it, and then every part lands together, or none does. See Plugin configurations for who approves what.

• A save that only tightens or changes values: under the default review you may approve it yourself, with Approve and apply.
• A save that loosens a control (an egress entry that widens, Ask to Allow, Refuse to Ask or Allow, a governance setting loosened) is always approved by another admin. A plugin's configuration that loosens always waits for another admin; a function's switch that loosens waits for another admin only where four eyes are on (two paths). This tab and oz0 plugin config apply are the first path; plugin install --config takes its settings and tools: the second way, and files the rest as this tab does.
• A save that touches the tool policy, the egress list or a governance setting takes a reason, which the audit log keeps.

When does a change reach work? Settings reach the plugin's processes at once. A model mapping applies to jobs that start after it is approved, and a budget to job trees that start after it.

Try a new model first

When a save changes an agent's model or its effort, the tab offers two runs before you save: the plugin's evals on the new model or level, and a paired comparison of the old and the new on recent jobs (see Measured savings). The change request links their results. Neither is required. A verified plugin whose model a mapping changed shows "verified; model changed by the tenant", here, in oz0 plugin show and on its agents' cards; other changes leave its badge as it is.

Roll back

Every applied configuration change has Roll back, on the Configure tab and on the Changes tab of Approvals. It files a new change request with the inverse diff, compared with the plugin as it is now, and is approved like any other.

The same as a file

Keep a plugin's configuration in your own repository:

oz0 plugin config export notes -o notes.yaml

format: oz0.plugin-config/v1
plugin: notes
settings:
  NOTES_INDEX: main
  NOTES_LIMIT: null       # not set: the plugin gets its default
models:
  - {agent: noter, from: default, to: eu-small, note: the EU model}
  - {agent: summarizer, from: fast, to: fast, effort: low}   # only the effort changes
tools:
  word_tools.count_words: allow
  word_tools.post_note: ask
skills:
  noter: {hidden: [old-format]}   # hidden from agent noter for this tenant; [] shows every one
budgets:
  noter: {max_cost_usd: 0.25, on_budget: wait}
agent_changes: {max: 3, period: 7d, cooldown: 72h}   # changesets agents may propose or apply to the plugin
egress: [api.notes.example.com]   # the tenant's list: every plugin's sandboxes may reach these
schedules:
  notes-nightly: {enabled: true}

oz0 plugin config apply notes.yaml --dry-run
oz0 plugin config apply notes.yaml --reason "the EU model for notes"
oz0 change approve <id>               # another admin, when it loosens a control
oz0 plugin config rollback <id> --reason "back to the old model"

• A file may hold only some parts, and only some entries of a part: what it leaves out stays as it is. null unsets a setting, an empty to removes a mapping rule, and egress: [] empties the tenant's list. A rule's effort is the reasoning effort its agents run at; with to the same as from, the rule changes only the effort.
• It never holds a secret's value: secrets are not part of a plugin's configuration.
• agent_changes is the plugin's change budget: max from 0 to 100, period from 1h to 90d, cooldown from 0 to 30d; a field it leaves out stays as it is.
• format is required, and a server refuses a format it does not read. Every key is checked, and the file is at most 1 MiB.
• --link <comparison id> links comparisons to the change request, as the tab's offer does.

The admin API has the same calls: GetPluginConfig, ExportPluginConfig, ApplyPluginConfig (with dry_run) and RollBackPluginConfig.