Module addons 

Addon ecosystem: community extensions for lean-ctx (#858).

An addon packages an external MCP server (+ metadata) behind a small lean-ctx-addon.toml manifest, so a third-party tool plugs into lean-ctx’s MCP gateway with a single lean-ctx addon add — no fork, no recompile. Addons are user-global and reuse the gateway trust model ([gateway] is global-only and opt-in; see crate::core::mcp_catalog).

Layers:

• manifest — the lean-ctx-addon.toml contract (also the registry entry shape).
• registry — the curated catalog (bundled, with optional user override).
• store — what is installed locally (<data_dir>/addons/installed.json).
• install — wires an addon into the gateway and records it in the store.
• bootstrap — [install] block executor: provisions an addon’s upstream package via a pinned package manager (uv/pip/cargo/npm/brew/dotnet) on add, uninstalls it on remove (#1105, Phase 2). Never goes through a shell.
• pack_env — expands {pack_dir:@ns/name} in an addon’s [mcp.env] to the on-disk location of a declared kind=skills dependency (#727).
• scaffold — addon init starter manifest generator (DX, P4).

Security (#863, P1):

• capabilities — the declared [capabilities] permission model that drives the per-addon sandbox + env allowlist + install consent.
• trust — trust tier (verified) + static risk assessment of the wiring.
• audit — capability-coherence + malware heuristics + the verified/paid gate (#403): does the declared [capabilities] match the wiring, and is the wiring free of malicious patterns?
• commerce — sellable-addon model ([pricing]) + the mandatory paid listing gate (Track B): no addon is sold without clearing the audit.
• binhash — SHA-256 binary pinning for stdio addons (refuse a swapped executable at spawn).
• policy — the global-only [addons] install policy floor + the gate.
• signing — Ed25519 signing for the user-override registry.
• revocation — central kill-switch that blocks a revoked addon from running (install, catalog build, every proxy call).
• integrity — install-time wiring hash + local re-verify (the lockfile).
• meter — per-addon / per-tool usage metering (analytics + billing base, P5).
• sandbox — per-addon OS sandbox for spawned stdio servers.
• runtime — redaction + audit of untrusted addon tool output.

Grammar addons (#690) are a separate, smaller concept living alongside this module rather than inside it — a long-tail tree-sitter grammar is a cdylib dlopen’d directly into lean-ctx’s own process, not an MCP server, so none of the subprocess/gateway-shaped layers above apply:

• grammar_manifest — the grammar-addon manifest (language, extensions, per-platform dylib + mandatory SHA-256 pin, tree-sitter ABI version).
• grammar_registry — its bundled/local-override catalog, reusing only signing and binhash from the MCP addon machinery.
• grammar_install (internal) — zero-config fetch (#690, Phase 1d): downloads a missing pinned dylib on first use, silent on any failure (offline, network error, hash mismatch) so it degrades to the regex-signature fallback exactly like “not installed” — no addon add consent step, since a grammar addon is a parsing fallback, not a spawned process.

Re-exports

pub use artifact_install::ArtifactAsset;

pub use artifact_install::current_target_triple;

pub use audit::AuditReport;

pub use audit::AuditVerdict;

pub use bootstrap::AddonInstall;

pub use bootstrap::BootstrapStatus;

pub use bootstrap::InstallReceipt;

pub use bootstrap::Manager;

pub use capabilities::AddonCapabilities;

pub use capabilities::FilesystemAccess;

pub use capabilities::NetworkAccess;

pub use commerce::AddonPricing;

pub use commerce::PaidGate;

pub use commerce::PricingModel;

pub use commerce::paid_listing_gate;

pub use grammar_manifest::GrammarAsset;

pub use grammar_manifest::GrammarManifest;

pub use health::ProbeReport;

pub use manifest::AddonManifest;

pub use manifest::AddonMcp;

pub use manifest::AddonMeta;

pub use policy::AddonPolicy;

pub use policy::AddonsConfig;

pub use sandbox::SandboxMode;

pub use store::InstalledAddon;

pub use store::InstalledStore;

pub use trust::RiskFinding;

pub use trust::RiskLevel;

pub use trust::TrustTier;

Modules

artifact_install

Unified artifact installer (GH #724/#725, Phase 1) — the one download → verify → atomic-install path for every managed binary artifact lean-ctx fetches: grammar dylibs (#690) and prebuilt addon binaries.

audit

Capability audit + publish gate for addons (P3, #403 — the gate before paid).

binhash

Binary-hash pinning for stdio addons (P3 — supply-chain hardening).

bootstrap

Addon bootstrap engine (#1105, Phase 2): install an addon’s upstream package through a real package manager as part of addon add, idempotently and with mandatory version pinning — then uninstall it on addon remove.

capabilities

Declared capability model for addons (P1 — platform keystone).

commerce

Sellable-addon commerce model (Track B — generalising the ctxpkg paid artifact to addons).

env_scrub

Environment scrubbing for spawned stdio addons (P1).

grammar_manifest

Grammar-addon manifest — long-tail tree-sitter grammars as signed dylibs (#690, Phase 1a).

grammar_registry

The curated grammar-addon catalog (#690, Phase 1a).

health

Post-install health probe (#1076).

install

Install / remove logic: wire an addon’s MCP server into the global gateway and record it in the installed store.

integrity

Addon integrity pinning + local re-verify (P2 — the lockfile half).

manifest

The lean-ctx-addon.toml manifest — the contract an addon author writes.

meter

Per-addon / per-tool usage metering (P5 — discovery & observability).

ort_provision

Managed ONNX Runtime provisioning (GH #732) — the consent-gated download that makes embeddings work out of the box, without owning a GPU driver matrix.

pack_env

{pack_dir:@ns/name} expansion for an addon’s [mcp.env] (GH #727).

policy

Install policy for addons — the org-controllable floor (#865).

publish

Build the distribution view of an addon (GH #724/#726, Phase 2): a signed kind=addon .ctxpkg whose content embeds the authoring lean-ctx-addon.toml verbatim.

registry

The curated addon catalog.

registry_snapshot

Canonical snapshot form of the bundled registries (GH #724/#726, Phase 2).

revocation

Central addon revocation / kill-switch (P2).

runtime

Runtime safeguards for addon tool output (#866).

sandbox

Opt-in OS sandbox for the stdio MCP servers an addon spawns (#865).

scaffold

lean-ctx addon init scaffolding (P4 — lower the floor).

signing

Detached Ed25519 signing for the user-override registry (#865).

store

Installed-addon state: <data_dir>/addons/installed.json.

trust

Trust tiers + static risk assessment for addons (#864).