Skip to main content

​
fluffbuzz plugins

Manage Gateway plugins/extensions, hook packs, and compatible bundles. Related:

​
Commands

fluffbuzz plugins list
fluffbuzz plugins install <path-or-spec>
fluffbuzz plugins inspect <id>
fluffbuzz plugins enable <id>
fluffbuzz plugins disable <id>
fluffbuzz plugins uninstall <id>
fluffbuzz plugins doctor
fluffbuzz plugins update <id>
fluffbuzz plugins update --all
fluffbuzz plugins marketplace list <marketplace>
Bundled plugins ship with FluffBuzz but start disabled. Use plugins enable to activate them. Native FluffBuzz plugins must ship fluffbuzz.plugin.json with an inline JSON Schema (configSchema, even if empty). Compatible bundles use their own bundle manifests instead. plugins list shows Format: fluffbuzz or Format: bundle. Verbose list/info output also shows the bundle subtype (codex, claude, or cursor) plus detected bundle capabilities.

​
Install

fluffbuzz plugins install <package>                      # ClawHub first, then npm
fluffbuzz plugins install buzzhub:<package>              # ClawHub only
fluffbuzz plugins install <package> --pin                # pin version
fluffbuzz plugins install <path>                         # local path
fluffbuzz plugins install <plugin>@<marketplace>         # marketplace
fluffbuzz plugins install <plugin> --marketplace <name>  # marketplace (explicit)
Bare package names are checked against ClawHub first, then npm. Security note: treat plugin installs like running code. Prefer pinned versions. plugins install is also the install surface for hook packs that expose fluffbuzz.hooks in package.json. Use fluffbuzz hooks for filtered hook visibility and per-hook enablement, not package installation. Npm specs are registry-only (package name + optional exact version or dist-tag). Git/URL/file specs and semver ranges are rejected. Dependency installs run with --ignore-scripts for safety. Bare specs and @latest stay on the stable track. If npm resolves either of those to a prerelease, FluffBuzz stops and asks you to opt in explicitly with a prerelease tag such as @beta/@rc or an exact prerelease version such as @1.2.3-beta.4. If a bare install spec matches a bundled plugin id (for example diffs), FluffBuzz installs the bundled plugin directly. To install an npm package with the same name, use an explicit scoped spec (for example @scope/diffs). Supported archives: .zip, .tgz, .tar.gz, .tar. Claude marketplace installs are also supported. ClawHub installs use an explicit buzzhub:<package> locator: 
fluffbuzz plugins install buzzhub:fluffbuzz-codex-app-server
fluffbuzz plugins install buzzhub:fluffbuzz-codex-app-server@1.2.3
FluffBuzz now also prefers ClawHub for bare npm-safe plugin specs. It only falls back to npm if ClawHub does not have that package or version: 
fluffbuzz plugins install fluffbuzz-codex-app-server
FluffBuzz downloads the package archive from ClawHub, checks the advertised plugin API / minimum gateway compatibility, then installs it through the normal archive path. Recorded installs keep their ClawHub source metadata for later updates. Use plugin@marketplace shorthand when the marketplace name exists in Claude’s local registry cache at ~/.claude/plugins/known_marketplaces.json: 
fluffbuzz plugins marketplace list <marketplace-name>
fluffbuzz plugins install <plugin-name>@<marketplace-name>
Use --marketplace when you want to pass the marketplace source explicitly: 
fluffbuzz plugins install <plugin-name> --marketplace <marketplace-name>
fluffbuzz plugins install <plugin-name> --marketplace <owner/repo>
fluffbuzz plugins install <plugin-name> --marketplace ./my-marketplace
Marketplace sources can be:
  • a Claude known-marketplace name from ~/.claude/plugins/known_marketplaces.json
  • a local marketplace root or marketplace.json path
  • a GitHub repo shorthand such as owner/repo
  • a git URL
For remote marketplaces loaded from GitHub or git, plugin entries must stay inside the cloned marketplace repo. FluffBuzz accepts relative path sources from that repo and rejects external git, GitHub, URL/archive, and absolute-path plugin sources from remote manifests. For local paths and archives, FluffBuzz auto-detects:
  • native FluffBuzz plugins (fluffbuzz.plugin.json)
  • Codex-compatible bundles (.codex-plugin/plugin.json)
  • Claude-compatible bundles (.claude-plugin/plugin.json or the default Claude component layout)
  • Cursor-compatible bundles (.cursor-plugin/plugin.json)
Compatible bundles install into the normal extensions root and participate in the same list/info/enable/disable flow. Today, bundle skills, Claude command-skills, Claude settings.json defaults, Cursor command-skills, and compatible Codex hook directories are supported; other detected bundle capabilities are shown in diagnostics/info but are not yet wired into runtime execution. Use --link to avoid copying a local directory (adds to plugins.load.paths): 
fluffbuzz plugins install -l ./my-plugin
Use --pin on npm installs to save the resolved exact spec (name@version) in plugins.installs while keeping the default behavior unpinned.

​
Uninstall

fluffbuzz plugins uninstall <id>
fluffbuzz plugins uninstall <id> --dry-run
fluffbuzz plugins uninstall <id> --keep-files
uninstall removes plugin records from plugins.entries, plugins.installs, the plugin allowlist, and linked plugins.load.paths entries when applicable. For active memory plugins, the memory slot resets to memory-core. By default, uninstall also removes the plugin install directory under the active state dir extensions root ($FLUFFBUZZ_STATE_DIR/extensions/<id>). Use --keep-files to keep files on disk. --keep-config is supported as a deprecated alias for --keep-files.

​
Update

fluffbuzz plugins update <id-or-npm-spec>
fluffbuzz plugins update --all
fluffbuzz plugins update <id-or-npm-spec> --dry-run
fluffbuzz plugins update @fluffbuzz/voice-call@beta
Updates apply to tracked installs in plugins.installs and tracked hook-pack installs in hooks.internal.installs. When you pass a plugin id, FluffBuzz reuses the recorded install spec for that plugin. That means previously stored dist-tags such as @beta and exact pinned versions continue to be used on later update <id> runs. For npm installs, you can also pass an explicit npm package spec with a dist-tag or exact version. FluffBuzz resolves that package name back to the tracked plugin record, updates that installed plugin, and records the new npm spec for future id-based updates. When a stored integrity hash exists and the fetched artifact hash changes, FluffBuzz prints a warning and asks for confirmation before proceeding. Use global --yes to bypass prompts in CI/non-interactive runs.

​
Inspect

fluffbuzz plugins inspect <id>
fluffbuzz plugins inspect <id> --json
Deep introspection for a single plugin. Shows identity, load status, source, registered capabilities, hooks, tools, commands, services, gateway methods, HTTP routes, policy flags, diagnostics, and install metadata. Each plugin is classified by what it actually registers at runtime:
  • plain-capability — one capability type (e.g. a provider-only plugin)
  • hybrid-capability — multiple capability types (e.g. text + speech + images)
  • hook-only — only hooks, no capabilities or surfaces
  • non-capability — tools/commands/services but no capabilities
See Plugin shapes for more on the capability model. The --json flag outputs a machine-readable report suitable for scripting and auditing. info is an alias for inspect.