plugin.toml manifest schema. For conceptual information, see Plugin Configuration.
Full example
[plugin]
Core plugin identity. This section is required.
[runtime]
Controls how the plugin runtime behaves. For guest plugins, the build process bakes these values into the plugin binary. For host plugins, the daemon reads them at registry scan time.
Plugin types
Execution contexts
State management
[runtime.paths]
All paths must be absolute. Guest plugins may use Windows-style absolute paths (e.g. C:\malbox\samples).
[runtime.stash]
[runtime.auto_collect]
Controls automatic file collection from artifact_dir and external_log_dir after each task completes. The runtime streams files in these directories back to the daemon as results, so your plugin does not need to send them explicitly.
For artifacts, the runtime skips files you already sent explicitly (via
ctx.results().push(PluginResult::file(...))) or marked with ctx.mark_collected() to avoid duplicates. External logs are always collected without deduplication.[runtime.auto_collect.artifacts]
[runtime.auto_collect.external_logs]
[events]
Configures event subscriptions for host plugins. Guest plugins do not support event hooks.
[events.filters.<EventName>]
Per-event-type filters. <EventName> is the event variant name (e.g. PluginResultAvailable).
[scope]
Required when state = "scoped". Defines the scope boundary for the plugin’s lifetime.
[results.<name>]
Declares result entries that this plugin may produce. Each key under [results] is a result name that matches what you pass to PluginResult::json("name", ...), PluginResult::bytes("name", ...), or PluginResult::file("name", ...).
Validation
The daemon validates the manifest when scanning plugin directories. It marks plugins with invalid manifests asInvalid in the registry and does not start them. The daemon enforces the following constraints:
Changing any runtime setting requires rebuilding the plugin (for guest plugins) or restarting the daemon (for host plugins).