Plugin manifest (velaclaw.plugin.json)
This page is for the native Velaclaw plugin manifest only. For compatible bundle layouts, see Plugin bundles. Compatible bundle formats use different manifest files:- Codex bundle:
.codex-plugin/plugin.json - Claude bundle:
.claude-plugin/plugin.jsonor the default Claude component layout without a manifest - Cursor bundle:
.cursor-plugin/plugin.json
velaclaw.plugin.json schema described here.
For compatible bundles, Velaclaw currently reads bundle metadata plus declared
skill roots, Claude command roots, Claude bundle settings.json defaults,
Claude bundle LSP defaults, and supported hook packs when the layout matches
Velaclaw runtime expectations.
Every native Velaclaw plugin must ship a velaclaw.plugin.json file in the
plugin root. Velaclaw uses this manifest to validate configuration
without executing plugin code. Missing or invalid manifests are treated as
plugin errors and block config validation.
See the full plugin system guide: Plugins.
For the native capability model and current external-compatibility guidance:
Capability model.
What this file does
velaclaw.plugin.json is the metadata Velaclaw reads before it loads your
plugin code.
Use it for:
- plugin identity
- config validation
- auth and onboarding metadata that should be available without booting plugin runtime
- cheap activation hints that control-plane surfaces can inspect before runtime loads
- cheap setup descriptors that setup/onboarding surfaces can inspect before runtime loads
- alias and auto-enable metadata that should resolve before plugin runtime loads
- shorthand model-family ownership metadata that should auto-activate the plugin before runtime loads
- static capability ownership snapshots used for bundled compat wiring and contract coverage
- cheap QA runner metadata that the shared
velaclaw qahost can inspect before plugin runtime loads - channel-specific config metadata that should merge into catalog and validation surfaces without loading runtime
- config UI hints
- registering runtime behavior
- declaring code entrypoints
- npm install metadata
package.json.
Minimal example
Rich example
Top-level field reference
providerAuthChoices reference
EachproviderAuthChoices entry describes one onboarding or auth choice.
Velaclaw reads this before provider runtime loads.
commandAliases reference
UsecommandAliases when a plugin owns a runtime command name that users may
mistakenly put in plugins.allow or try to run as a root CLI command. Velaclaw
uses this metadata for diagnostics without importing plugin runtime code.
activation reference
Useactivation when the plugin can cheaply declare which control-plane events
should activate it later.
qaRunners reference
UseqaRunners when a plugin contributes one or more transport runners beneath
the shared velaclaw qa root. Keep this metadata cheap and static; the plugin
runtime still owns actual CLI registration through a lightweight
runtime-api.ts surface that exports qaRunnerCliRegistrations.
This block is metadata only. It does not register runtime behavior, and it does
not replace
register(...), setupEntry, or other runtime/plugin entrypoints.
Current consumers use it as a narrowing hint before broader plugin loading, so
missing activation metadata usually only costs performance; it should not
change correctness while legacy manifest ownership fallbacks still exist.
Current live consumers:
- command-triggered CLI planning falls back to legacy
commandAliases[].cliCommandorcommandAliases[].name - channel-triggered setup/channel planning falls back to legacy
channels[]ownership when explicit channel activation metadata is missing - provider-triggered setup/runtime planning falls back to legacy
providers[]and top-levelcliBackends[]ownership when explicit provider activation metadata is missing
setup reference
Usesetup when setup and onboarding surfaces need cheap plugin-owned metadata
before runtime loads.
cliBackends stays valid and continues to describe CLI inference
backends. setup.cliBackends is the setup-specific descriptor surface for
control-plane/setup flows that should stay metadata-only.
When present, setup.providers and setup.cliBackends are the preferred
descriptor-first lookup surface for setup discovery. If the descriptor only
narrows the candidate plugin and setup still needs richer setup-time runtime
hooks, set requiresRuntime: true and keep setup-api in place as the
fallback execution path.
Because setup lookup can execute plugin-owned setup-api code, normalized
setup.providers[].id and setup.cliBackends[] values must stay unique across
discovered plugins. Ambiguous ownership fails closed instead of picking a
winner from discovery order.
setup.providers reference
setup fields
uiHints reference
uiHints is a map from config field names to small rendering hints.
contracts reference
Usecontracts only for static capability ownership metadata that Velaclaw can
read without importing the plugin runtime.
channelConfigs reference
UsechannelConfigs when a channel plugin needs cheap config metadata before
runtime loads.
modelSupport reference
UsemodelSupport when Velaclaw should infer your provider plugin from
shorthand model ids like gpt-5.4 or claude-sonnet-4.6 before plugin runtime
loads.
- explicit
provider/modelrefs use the owningprovidersmanifest metadata modelPatternsbeatmodelPrefixes- if one non-bundled plugin and one bundled plugin both match, the non-bundled plugin wins
- remaining ambiguity is ignored until the user or config specifies a provider
Legacy top-level capability keys are deprecated. Use
velaclaw doctor --fix to
move speechProviders, realtimeTranscriptionProviders,
realtimeVoiceProviders, mediaUnderstandingProviders,
imageGenerationProviders, videoGenerationProviders,
webFetchProviders, and webSearchProviders under contracts; normal
manifest loading no longer treats those top-level fields as capability
ownership.
Manifest versus package.json
The two files serve different jobs:
If you are unsure where a piece of metadata belongs, use this rule:
- if Velaclaw must know it before loading plugin code, put it in
velaclaw.plugin.json - if it is about packaging, entry files, or npm install behavior, put it in
package.json
package.json fields that affect discovery
Some pre-runtime plugin metadata intentionally lives inpackage.json under the
velaclaw block instead of velaclaw.plugin.json.
Important examples:
velaclaw.install.minHostVersion is enforced during install and manifest
registry loading. Invalid values are rejected; newer-but-valid values skip the
plugin on older hosts.
velaclaw.install.allowInvalidConfigRecovery is intentionally narrow. It does
not make arbitrary broken configs installable. Today it only allows install
flows to recover from specific stale bundled-plugin upgrade failures, such as a
missing bundled plugin path or a stale channels.<id> entry for that same
bundled plugin. Unrelated config errors still block install and send operators
to velaclaw doctor --fix.
velaclaw.channel.persistedAuthState is package metadata for a tiny checker
module:
velaclaw.channel.configuredState follows the same shape for cheap env-only
configured checks:
config.hasConfiguredState
hook instead.
JSON Schema requirements
- Every plugin must ship a JSON Schema, even if it accepts no config.
- An empty schema is acceptable (for example,
{ "type": "object", "additionalProperties": false }). - Schemas are validated at config read/write time, not at runtime.
Validation behavior
- Unknown
channels.*keys are errors, unless the channel id is declared by a plugin manifest. plugins.entries.<id>,plugins.allow,plugins.deny, andplugins.slots.*must reference discoverable plugin ids. Unknown ids are errors.- If a plugin is installed but has a broken or missing manifest or schema, validation fails and Doctor reports the plugin error.
- If plugin config exists but the plugin is disabled, the config is kept and a warning is surfaced in Doctor + logs.
plugins.* schema.
Notes
- The manifest is required for native Velaclaw plugins, including local filesystem loads.
- Runtime still loads the plugin module separately; the manifest is only for discovery + validation.
- Native manifests are parsed with JSON5, so comments, trailing commas, and unquoted keys are accepted as long as the final value is still an object.
- Only documented manifest fields are read by the manifest loader. Avoid adding custom top-level keys here.
providerAuthEnvVarsis the cheap metadata path for auth probes, env-marker validation, and similar provider-auth surfaces that should not boot plugin runtime just to inspect env names.providerAuthAliaseslets provider variants reuse another provider’s auth env vars, auth profiles, config-backed auth, and API-key onboarding choice without hardcoding that relationship in core.channelEnvVarsis the cheap metadata path for shell-env fallback, setup prompts, and similar channel surfaces that should not boot plugin runtime just to inspect env names.providerAuthChoicesis the cheap metadata path for auth-choice pickers,--auth-choiceresolution, preferred-provider mapping, and simple onboarding CLI flag registration before provider runtime loads. For runtime wizard metadata that requires provider code, see Provider runtime hooks.- Exclusive plugin kinds are selected through
plugins.slots.*.kind: "memory"is selected byplugins.slots.memory.kind: "context-engine"is selected byplugins.slots.contextEngine(default: built-inlegacy).
channels,providers,cliBackends, andskillscan be omitted when a plugin does not need them.- If your plugin depends on native modules, document the build steps and any
package-manager allowlist requirements (for example, pnpm
allow-build-scriptspnpm rebuild <package>).
Related
- Building Plugins — getting started with plugins
- Plugin Architecture — internal architecture
- SDK Overview — Plugin SDK reference