Plugins

The Plugins panel is the control center for add-ons that extend Zimac with pages, commands, or Studios. It keeps installation separate from review, capability approval, and activation.

What plugins add#

An enabled plugin can contribute one or more extension surfaces declared by its manifest, including app pages, slash commands, and specialist-style Studios. Its interface runs inside a restricted plugin frame and reaches privileged features through Zimac’s capability broker.

Installed files live in the local Zimac plugins directory. Plugin-specific state is also local. A plugin appearing in the list does not mean it is active: newly installed or replaced plugins arrive disabled.

Install#

Store

The Store tab loads Zimac’s curated index and marks installed entries and available updates. During installation, Zimac verifies the downloaded bundle against the checksum published in that index, then installs it disabled. If the network is unavailable, the Store may show a cached catalog whose availability or versions are stale.

Local bundle

Choose Install .zplugin to import a single JSON bundle exported by Plugin Studio or another trusted source. Zimac validates its manifest and files before placing it in the plugin directory. If its ID matches an installed plugin, replacement is explicit and the old approval is cleared.

Review#

Each plugin receives a review verdict—safe, suspicious, or dangerous—with findings you can inspect. The review combines deterministic checks for risky constructs with model-assisted explanation when a review model is available.

• Critical static findings block ordinary enablement.
• A dangerous result requires a separate explicit Enable anyway decision where the UI permits an override.
• If model review is unavailable, the absence of that opinion is shown; it is not silently converted into proof of safety.
• Re-scan refreshes findings but does not itself approve or enable the plugin.

Review the source and provenance yourself when the plugin handles important data. Automated findings are decision support, not a security certification.

Enable & approve#

1. 1
   Read the manifest and findings.

   Confirm that the plugin identity, origin, code, and requested features match what you intended to install.

2. 2
   Approve capabilities.

   The enable flow lists the privileges the plugin requests. Approval applies only to the selected subset, not to undeclared future access.

3. 3
   Enable the reviewed bytes.

   Zimac records a hash of the approved plugin folder. Only that reviewed version is activated.

If any plugin file changes afterward—even a bundled asset—the hash no longer matches. Zimac marks it Changed since approved and prevents the old approval from authorizing the changed bytes. Re-scan, review the change, and enable it again.

Capabilities & sandbox#

The runtime isolates plugin UI and exposes approved operations through a broker. A capability can be used only when it is declared, approved for the current plugin hash, and allowed by the runtime. Network requests are additionally constrained to approved HTTP origins.

This model limits accidental reach, but a granted capability is real authority. A plugin approved for storage or a network origin can use that access while enabled. Approve the minimum set and disable plugins you are not using.

Update, export & remove#

• Update or replace installs new bytes disabled and clears the previous capability approval. Review and enable the new version.
• Disable removes the plugin’s active contributions without deleting its files or local state.
• Export packages an installed plugin as a .zplugin file for inspection or transfer.
• Uninstall deletes the plugin folder, approval and review records, and stored plugin data. Treat this as destructive; export anything you need first.

Trust boundary#

• A Store checksum proves that the downloaded bytes match the indexed bundle. It does not prove that the bundle is harmless.
• “Curated” describes the distribution index, not an unconditional security guarantee.
• Model review can miss behavior or misclassify intent; static checks cover a finite set of patterns.
• Capability approval limits brokered APIs, not the consequences of data you intentionally give a plugin.
• Plugins are local add-ons, not team-synced applications or cloud-hosted services.