Navide plugins extend Navide itself — they are not the CLI extensions an AI CLI installs for itself. Each plugin has its own frontend and backend, and everything published to the Navide Marketplace uses Manifest v2.
Design principle: disclose, don't restrict
This is the governing rule for every plugin, permission, capability and Marketplace decision. Effective disclosure is the core value of the Navide Marketplace.
- A plugin is a full program. The platform does not cap what a plugin may do with framework limits, capability allowlists or mutually exclusive permissions.
- Every power is declared, disclosed and consented to. Anything a plugin can do — files, shell commands, a native backend, network, tools offered to agents — is declared in its manifest. The user sees it in plain language, with its risk level, before installing, and grants it explicitly. A version that adds a power asks again and shows exactly what changed.
- Disclosure must be effective, not merely present. It is shown where the decision is made: the listing and detail page, not only a dialog after "Install". What a plugin actually did at run time is shown too, not only what it declared.
- What the platform keeps is protection against deception, not
restriction. Signatures and digests, the reserved
navide.namespace, tool names that cannot impersonate built-in tools, caller identity, and labelling third-party output as external stop one party from pretending to be another; they do not limit what an honest plugin can do.
What you build with
Third-party plugins may depend only on three public packages:
@navide/plugin-contracts— manifest types, capability addresses, payloads, error codes, and JSON Schema exports.@navide/plugin-sdk— activation, capability calls, events, lifecycle, view, and target APIs. It also ships thenavide-plugincommand-line tool.@navide/plugin-ui— Vue components, shared presentation services, stable design tokens, and safe capability-backed UI controllers.
Official and third-party packages use the same public dependency graph and the same install, activation, update, rollback, and uninstall lifecycle. Official status changes only Registry trust and marketplace classification.
Compatibility commitment (1.x)
The three public packages share one version and follow SemVer 2.0.0. Within the 1.x line Navide commits to:
- Additions only. Anything that exists in a 1.x release keeps working in every later 1.x release.
- Twelve months' notice. Something that has to go is marked deprecated and keeps working for at least twelve months; it is removed only in the next major.
- The Host keeps installing 1.x manifests. A package whose
apiVersionis^1.0.0keeps installing and running for the same period after a 2.0.0 ships. - Fixes are patches. A behavior change that corrects a documented contract ships as a patch release.
The static scan, the Registry's manifest validation and the Host's disclosure
contract are versioned with the packages, so a manifest that
navide-plugin validate accepts at 1.x is accepted by the Registry of the same
1.x line.
From a folder to a Marketplace listing
The navide-plugin CLI covers the whole publishing workflow.
- Scaffold.
navide-plugin init <directory> --id <namespace.name>creates the source project. - Declare and validate. Declare the permissions your plugin needs in its
manifest, then run
navide-plugin validate <directory>. - Scan.
navide-plugin scan <package.vsix | directory>runs the static scan. The Registry's scan compares the commands and network hosts it finds in the code with what the manifest declares; anything found but not declared is shown in red. - Try it in Navide. Turn on Developer Mode in Settings → Navide Plugins
and choose Load from folder…. The folder reloads by itself when its
files change.
navide-plugin dev-backend <directory>runs a backend on its own. There is nonavide-plugin devcommand. - Package and sign.
navide-plugin packagebuilds the package (per target for a backend),navide-plugin keygencreates a publisher key the first time, andnavide-plugin signsigns the package. - Publish. With your developer qualification approved (see below), sign
in at developers.navide.dev/publish
with your Navide account and claim a namespace. Then submit each version
either from the CLI, with
navide-plugin loginandnavide-plugin publish, or withnavide-plugin publish --via-navide, which hands the package to the publish form in the Navide app. A version is listed after a review.
No sign-up to start building
There is nothing to apply for or discuss before you start building. When your plugin is ready, two reviews stand between it and the Navide Marketplace:
- Developer qualification, once per Navide account. Only an approved developer can claim a namespace or get a publish token. The application is real-name (legal name, contact email, country, the namespace you intend to claim, what you will publish); the Marketplace shows only your display name. Review checks who is publishing and that you can be reached, never which permissions your plugins ask for. A rejection comes with a reason and you can apply again. Apply on the Developer application page of the developer console, developers.navide.dev/developer/apply, or from the Navide app.
- Every version, before it is public. Each version is reviewed by a
person; until then it is invisible to search, the listing page and the
Navide app. The reviewer sees its signature, its name compared with
existing extensions, a secret scan of the package contents, every
permission it declares (sensitive ones flagged), and its size against the
200 MiB limit. The target is a decision within 3 business days; there is no
automatic approval. A rejection carries a reason: fix it and publish a new
version. Check where a version stands with
navide-plugin status, or under Versions & review status on your namespace's dashboard.
Working with an agent? Navide ships a skill for this workflow: the agent calls
skills_prepare_install with the source navide:plugin-authoring, and you
approve the install in the main window.
Full specification
- Plugin Developer Spec v2 — the manifest, SDK, permissions and compatibility contract.
- Plugin development guide — the legacy manifest v1 runtime, packaging and Registry endpoints.
- Publishing to the Navide Marketplace — developer qualification, namespaces, signing, publishing and review, step by step.