Plugins

Manage Gateway plugins, hook packs, and compatible bundles.

End-user guide for installing, enabling, and troubleshooting plugins. Quick examples for install, list, update, uninstall, and publishing. Bundle compatibility model. Manifest fields and config schema. Security hardening for plugin installs.

Commands

remoteclaw plugins list
remoteclaw plugins list --enabled
remoteclaw plugins list --verbose
remoteclaw plugins list --json
remoteclaw plugins search <query>
remoteclaw plugins search <query> --limit 20
remoteclaw plugins search <query> --json
remoteclaw plugins install <path-or-spec>
remoteclaw plugins inspect <id>
remoteclaw plugins inspect <id> --runtime
remoteclaw plugins inspect <id> --json
remoteclaw plugins inspect --all
remoteclaw plugins info <id>
remoteclaw plugins enable <id>
remoteclaw plugins disable <id>
remoteclaw plugins registry
remoteclaw plugins registry --refresh
remoteclaw plugins uninstall <id>
remoteclaw plugins doctor
remoteclaw plugins update <id-or-npm-spec>
remoteclaw plugins update --all
remoteclaw plugins marketplace list <marketplace>
remoteclaw plugins marketplace list <marketplace> --json
remoteclaw plugins init <id>
remoteclaw plugins init <id> --directory ./my-plugin --name "My Plugin"
remoteclaw plugins build --entry ./dist/index.js
remoteclaw plugins build --entry ./dist/index.js --check
remoteclaw plugins validate --entry ./dist/index.js

For slow install, inspect, uninstall, or registry-refresh investigation, run the command with REMOTECLAW_PLUGIN_LIFECYCLE_TRACE=1. The trace writes phase timings to stderr and keeps JSON output parseable. See Debugging.

In Nix mode (`REMOTECLAW_NIX_MODE=1`), plugin lifecycle mutators are disabled. Use the Nix source for this install instead of `plugins install`, `plugins update`, `plugins uninstall`, `plugins enable`, or `plugins disable`; for nix-remoteclaw, use the agent-first [Quick Start](https://github.com/remoteclaw/nix-remoteclaw#quick-start). Bundled plugins ship with RemoteClaw. Some are enabled by default (for example bundled model providers, bundled speech providers, and the bundled browser plugin); others require `plugins enable`.

Native RemoteClaw plugins must ship remoteclaw.plugin.json with an inline JSON Schema (configSchema, even if empty). Compatible bundles use their own bundle manifests instead.

plugins list shows Format: remoteclaw or Format: bundle. Verbose list/info output also shows the bundle subtype (codex, claude, or cursor) plus detected bundle capabilities.

Author

remoteclaw plugins init stock-quotes --name "Stock Quotes"
cd stock-quotes
npm run plugin:build
npm run plugin:validate

plugins init creates a minimal TypeScript tool plugin that uses defineToolPlugin. plugins build imports that entry, reads its static tool metadata, writes remoteclaw.plugin.json, and keeps package.json remoteclaw.extensions aligned. plugins validate checks that the generated manifest, package metadata, and current entry export still agree. See Tool Plugins for the full authoring workflow.

The scaffold writes TypeScript source but generates metadata from the built ./dist/index.js entry so the workflow also works with the published CLI. Use --entry <path> when the entry is not the default package entry. Use plugins build --check in CI to fail when generated metadata is stale without rewriting files.

Install

remoteclaw plugins search "calendar"                   # search ClawHub plugins
remoteclaw plugins install <package>                      # source auto-detection
remoteclaw plugins install clawhub:<package>              # ClawHub only
remoteclaw plugins install npm:<package>                  # npm only
remoteclaw plugins install npm-pack:<path.tgz>            # local npm pack through npm install semantics
remoteclaw plugins install git:github.com/<owner>/<repo>  # git repo
remoteclaw plugins install git:github.com/<owner>/<repo>@<ref>
remoteclaw plugins install <package> --force              # overwrite existing install
remoteclaw plugins install <package> --pin                # pin version
remoteclaw plugins install <package> --dangerously-force-unsafe-install
remoteclaw plugins install <path>                         # local path
remoteclaw plugins install <plugin>@<marketplace>         # marketplace
remoteclaw plugins install <plugin> --marketplace <name>  # marketplace (explicit)
remoteclaw plugins install <plugin> --marketplace https://github.com/<owner>/<repo>

Maintainers testing setup-time installs can override automatic plugin install sources with guarded environment variables. See Plugin install overrides.

Bare package names install from npm by default during the launch cutover, unless they match an official plugin id. Raw `@remoteclaw/*` package specs that match bundled plugins use the bundled copy that shipped with the current RemoteClaw build. Use `npm:` when you deliberately want an external npm package instead. Use `clawhub:` for ClawHub. Treat plugin installs like running code. Prefer pinned versions.

plugins search queries ClawHub for installable plugin packages and prints install-ready package names. It searches code-plugin and bundle-plugin packages, not skills. Use remoteclaw skills search for ClawHub skills.

ClawHub is the primary distribution and discovery surface for most plugins. Npm remains a supported fallback and direct-install path. RemoteClaw-owned `@remoteclaw/*` plugin packages are published on npm again; see the current list on [npmjs.com/org/remoteclaw](https://www.npmjs.com/org/remoteclaw) or the [plugin inventory](/plugins/plugin-inventory). Stable installs use `latest`. Beta-channel installs and updates prefer the npm `beta` dist-tag when that tag is available, then fall back to `latest`. If your `plugins` section is backed by a single-file `$include`, `plugins install/update/enable/disable/uninstall` write through to that included file and leave `remoteclaw.json` untouched. Root includes, include arrays, and includes with sibling overrides fail closed instead of flattening. See [Config includes](/gateway/configuration) for the supported shapes.

If config is invalid during install, `plugins install` normally fails closed and tells you to run `remoteclaw doctor --fix` first. During Gateway startup and hot reload, invalid plugin config fails closed like any other invalid config; `remoteclaw doctor --fix` can quarantine the invalid plugin entry. The only documented install-time exception is a narrow bundled-plugin recovery path for plugins that explicitly opt into `remoteclaw.install.allowInvalidConfigRecovery`.

`--force` reuses the existing install target and overwrites an already-installed plugin or hook pack in place. Use it when you are intentionally reinstalling the same id from a new local path, archive, ClawHub package, or npm artifact. For routine upgrades of an already tracked npm plugin, prefer `remoteclaw plugins update `.

If you run `plugins install` for a plugin id that is already installed, RemoteClaw stops and points you at `plugins update <id-or-npm-spec>` for a normal upgrade, or at `plugins install <package> --force` when you genuinely want to overwrite the current install from a different source.

`--pin` applies to npm installs only. It is not supported with `git:` installs; use an explicit git ref such as `git:github.com/acme/plugin@v1.2.3` when you want a pinned source. It is not supported with `--marketplace`, because marketplace installs persist marketplace source metadata instead of an npm spec. `--dangerously-force-unsafe-install` is deprecated and is now a no-op. OpenClaw no longer runs built-in install-time dangerous-code blocking for plugin installs.

Use the shared operator-owned `security.installPolicy` surface when host-specific install policy is required. Plugin `before_install` hooks and `security.installPolicy` can still block installs.

If a plugin you published on ClawHub is hidden or blocked by a registry scan, use the publisher steps in [ClawHub publishing](/clawhub/publishing). `--dangerously-force-unsafe-install` does not ask ClawHub to rescan the plugin or make a blocked release public.

`plugins install` is also the install surface for hook packs that expose `remoteclaw.hooks` in `package.json`. Use `remoteclaw 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 in one managed npm project per plugin with `--ignore-scripts` for safety, even when your shell has global npm install settings. Managed plugin npm projects inherit RemoteClaw's package-level npm `overrides`, so host security pins apply to hoisted plugin dependencies too.

Use `npm:<package>` when you want to make npm resolution explicit. Bare package specs also install directly from npm during the launch cutover unless they match an official plugin id.

Raw `@remoteclaw/*` package specs that match bundled plugins resolve to the image-owned bundled copy before npm fallback. For example, `remoteclaw plugins install @remoteclaw/discord@2026.5.20 --pin` uses the bundled Discord plugin from the current RemoteClaw build instead of creating a managed npm override. To force the external npm package, use `remoteclaw plugins install npm:@remoteclaw/discord@2026.5.20 --pin`.

Bare specs and `@latest` stay on the stable track. RemoteClaw date-stamped correction versions such as `2026.5.3-1` are stable releases for this check. If npm resolves either of those to a prerelease, RemoteClaw 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`.

For npm installs without an exact version (`npm:<package>` or `npm:<package>@latest`), RemoteClaw checks the resolved package metadata before install. If the latest stable package requires a newer RemoteClaw plugin API or minimum host version, RemoteClaw inspects older stable versions and installs the newest compatible release instead. Exact versions and explicit dist-tags such as `@beta` remain strict: if the selected package is incompatible, the command fails and asks you to upgrade RemoteClaw or choose a compatible version.

If a bare install spec matches an official plugin id (for example `diffs`), RemoteClaw installs the catalog entry directly. To install an npm package with the same name, use an explicit scoped spec (for example `@scope/diffs`).

Use `git:` to install directly from a git repository. Supported forms include `git:github.com/owner/repo`, `git:owner/repo`, full `https://`, `ssh://`, `git://`, `file://`, and `git@host:owner/repo.git` clone URLs. Add `@` or `#` to check out a branch, tag, or commit before install.

Git installs clone into a temporary directory, check out the requested ref when present, then use the normal plugin directory installer. That means manifest validation, operator install policy, package-manager install work, and install records behave like npm installs. Recorded git installs include the source URL/ref plus the resolved commit so `openclaw plugins update` can re-resolve the source later.

After installing from git, use `remoteclaw plugins inspect <id> --runtime --json` to verify runtime registrations such as gateway methods and CLI commands. If the plugin registered a CLI root with `api.registerCli`, execute that command directly through the RemoteClaw root CLI, for example `remoteclaw demo-plugin ping`.

Supported archives: `.zip`, `.tgz`, `.tar.gz`, `.tar`. Native RemoteClaw plugin archives must contain a valid `remoteclaw.plugin.json` at the extracted plugin root; archives that only contain `package.json` are rejected before RemoteClaw writes install records.

Use `npm-pack:<path.tgz>` when the file is an npm-pack tarball and you want
to test the same per-plugin managed npm project path used by registry
installs, including `package-lock.json` verification, hoisted dependency
scanning, and npm install records. Plain archive paths still install as local
archives under the plugin extensions root.

Claude marketplace installs are also supported.

ClawHub installs use an explicit clawhub:<package> locator:

remoteclaw plugins install clawhub:remoteclaw-codex-app-server
remoteclaw plugins install clawhub:remoteclaw-codex-app-server@1.2.3

Bare npm-safe plugin specs install from npm by default during the launch cutover unless they match an official plugin id:

remoteclaw plugins install remoteclaw-codex-app-server

Use npm: to make npm-only resolution explicit:

remoteclaw plugins install npm:remoteclaw-codex-app-server
remoteclaw plugins install npm:@remoteclaw/discord@2026.5.20
remoteclaw plugins install npm:@scope/plugin-name@1.0.1

RemoteClaw checks the advertised plugin API / minimum gateway compatibility before install. When the selected ClawHub version publishes a ClawPack artifact, RemoteClaw downloads the versioned npm-pack .tgz, verifies the ClawHub digest header and the artifact digest, then installs it through the normal archive path. Older ClawHub versions without ClawPack metadata still install through the legacy package archive verification path. Recorded installs keep their ClawHub source metadata, artifact kind, npm integrity, npm shasum, tarball name, and ClawPack digest facts for later updates. Unversioned ClawHub installs keep an unversioned recorded spec so remoteclaw plugins update can follow newer ClawHub releases; explicit version or tag selectors such as clawhub:pkg@1.2.3 and clawhub:pkg@beta remain pinned to that selector.

Marketplace shorthand

Use plugin@marketplace shorthand when the marketplace name exists in Claude’s local registry cache at ~/.claude/plugins/known_marketplaces.json:

remoteclaw plugins marketplace list <marketplace-name>
remoteclaw plugins install <plugin-name>@<marketplace-name>

Use --marketplace when you want to pass the marketplace source explicitly:

remoteclaw plugins install <plugin-name> --marketplace <marketplace-name>
remoteclaw plugins install <plugin-name> --marketplace <owner/repo>
remoteclaw plugins install <plugin-name> --marketplace https://github.com/<owner>/<repo>
remoteclaw plugins install <plugin-name> --marketplace ./my-marketplace

- 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 GitHub repo URL such as `https://github.com/owner/repo` - a git URL For remote marketplaces loaded from GitHub or git, plugin entries must stay inside the cloned marketplace repo. RemoteClaw accepts relative path sources from that repo and rejects HTTP(S), absolute-path, git, GitHub, and other non-path plugin sources from remote manifests.

For local paths and archives, RemoteClaw auto-detects:

• native RemoteClaw plugins (remoteclaw.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)

Managed local installs must be plugin directories or archives. Standalone .js, .mjs, .cjs, and .ts plugin files are not copied into the managed plugin root by plugins install; list them explicitly in plugins.load.paths instead.

Compatible bundles install into the normal plugin root and participate in the same list/info/enable/disable flow. Today, bundle skills, Claude command-skills, Claude `settings.json` defaults, Claude `.lsp.json` / manifest-declared `lspServers` 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.

List

remoteclaw plugins list
remoteclaw plugins list --enabled
remoteclaw plugins list --verbose
remoteclaw plugins list --json
remoteclaw plugins search <query>
remoteclaw plugins search <query> --limit 20
remoteclaw plugins search <query> --json

Show only enabled plugins. Switch from the table view to per-plugin detail lines with source/origin/version/activation metadata. Machine-readable inventory plus registry diagnostics and package dependency install state. `plugins list` reads the persisted local plugin registry first, with a manifest-only derived fallback when the registry is missing or invalid. It is useful for checking whether a plugin is installed, enabled, and visible to cold startup planning, but it is not a live runtime probe of an already-running Gateway process. After changing plugin code, enablement, hook policy, or `plugins.load.paths`, restart the Gateway that serves the channel before expecting new `register(api)` code or hooks to run. For remote/container deployments, verify you are restarting the actual `remoteclaw gateway run` child, not only a wrapper process.

plugins list --json includes each plugin’s dependencyStatus from package.json dependencies and optionalDependencies. RemoteClaw checks whether those package names are present along the plugin’s normal Node node_modules lookup path; it does not import plugin runtime code, run a package manager, or repair missing dependencies.

If startup logs plugins.allow is empty; discovered non-bundled plugins may auto-load: ..., run remoteclaw plugins list --enabled --verbose or remoteclaw plugins inspect <id> with a listed plugin id to confirm the plugin ids and copy trusted ids into plugins.allow in remoteclaw.json. When the warning can list every discovered plugin, it prints a ready-to-paste plugins.allow snippet that already includes those ids. If a plugin loads without install/load-path provenance, inspect that plugin id, then either pin the trusted id in plugins.allow or reinstall the plugin from a trusted source so RemoteClaw records install provenance.

plugins search is a remote ClawHub catalog lookup. It does not inspect local state, mutate config, install packages, or load plugin runtime code. Search results include the ClawHub package name, family, channel, version, summary, and an install hint such as remoteclaw plugins install clawhub:<package>.

For bundled plugin work inside a packaged Docker image, bind-mount the plugin source directory over the matching packaged source path, such as /app/extensions/synology-chat. RemoteClaw will discover that mounted source overlay before /app/dist/extensions/synology-chat; a plain copied source directory remains inert so normal packaged installs still use compiled dist.

For runtime hook debugging:

• remoteclaw plugins inspect <id> --runtime --json shows registered hooks and diagnostics from a module-loaded inspection pass. Runtime inspection never installs dependencies; use remoteclaw doctor --fix to clean legacy dependency state or recover missing downloadable plugins that are referenced by config.
• remoteclaw gateway status --deep --require-rpc confirms the reachable Gateway URL/profile, service/process hints, config path, and RPC health.
• Non-bundled conversation hooks (llm_input, llm_output, before_model_resolve, before_agent_reply, before_agent_run, before_agent_finalize, agent_end) require plugins.entries.<id>.hooks.allowConversationAccess=true.

Use --link to avoid copying a local plugin directory (adds to plugins.load.paths):

remoteclaw plugins install -l ./my-plugin

Standalone plugin files must be listed in plugins.load.paths rather than installed with plugins install or placed directly in ~/.openclaw/extensions or <workspace>/.openclaw/extensions. Those auto-discovered roots load plugin package or bundle directories, while top-level script files are treated as local helpers and skipped.

Workspace-origin plugins discovered from a workspace extensions root are not imported or executed until they are explicitly enabled. For local development, run `remoteclaw plugins enable ` or set `plugins.entries..enabled: true`; if your config uses `plugins.allow`, include the same plugin id there too. This fail-closed rule also applies when channel setup explicitly targets a workspace-origin plugin for setup-only loading, so local channel plugin setup code will not run while that workspace plugin remains disabled or excluded from the allowlist. Linked installs and explicit `plugins.load.paths` entries follow the normal policy for their resolved plugin origin. See [Configure plugin policy](/tools/plugin#configure-plugin-policy) and [Configuration reference](/gateway/configuration-reference#plugins).

--force is not supported with --link because linked installs reuse the source path instead of copying over a managed install target.

Use --pin on npm installs to save the resolved exact spec (name@version) in the managed plugin index while keeping the default behavior unpinned.

Plugin index

Plugin install metadata is machine-managed state, not user config. Installs and updates write it to the shared SQLite state database under the active RemoteClaw state directory. The installed_plugin_index row stores durable installRecords metadata, including records for broken or missing plugin manifests, plus a manifest-derived cold registry cache used by remoteclaw plugins update, uninstall, diagnostics, and the cold plugin registry.

When RemoteClaw sees shipped legacy plugins.installs records in config, runtime reads treat them as compatibility input without rewriting remoteclaw.json. Explicit plugin writes and remoteclaw doctor --fix move those records into the plugin index and remove the config key when config writes are allowed; if either write fails, the config records are kept so the install metadata is not lost.

Uninstall

remoteclaw plugins uninstall <id>
remoteclaw plugins uninstall <id> --dry-run
remoteclaw plugins uninstall <id> --keep-files

uninstall removes plugin records from plugins.entries, the persisted plugin index, plugin allow/deny list entries, and linked plugins.load.paths entries when applicable. Unless --keep-files is set, uninstall also removes the tracked managed install directory when it is inside RemoteClaw’s plugin extensions root. For active memory plugins, the memory slot resets to memory-core.

`--keep-config` is supported as a deprecated alias for `--keep-files`.

Update

remoteclaw plugins update <id-or-npm-spec>
remoteclaw plugins update --all
remoteclaw plugins update <id-or-npm-spec> --dry-run
remoteclaw plugins update @remoteclaw/voice-call
remoteclaw plugins update remoteclaw-codex-app-server --dangerously-force-unsafe-install

Updates apply to tracked plugin installs in the managed plugin index and tracked hook-pack installs in hooks.internal.installs.

When you pass a plugin id, RemoteClaw 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 ` runs.

For npm installs, you can also pass an explicit npm package spec with a dist-tag or exact version. RemoteClaw 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.

Passing the npm package name without a version or tag also resolves back to the tracked plugin record. Use this when a plugin was pinned to an exact version and you want to move it back to the registry's default release line.

`remoteclaw plugins update` reuses the tracked plugin spec unless you pass a new spec. `remoteclaw update` additionally knows the active RemoteClaw update channel: on the beta channel, default-line npm and ClawHub plugin records try `@beta` first. They fall back to the recorded default/latest spec if no plugin beta release exists; npm plugins also fall back when the beta package exists but fails install validation. That fallback is reported as a warning and does not fail the core update. Exact versions and explicit tags stay pinned to that selector. Before a live npm update, RemoteClaw checks the installed package version against the npm registry metadata. If the installed version and recorded artifact identity already match the resolved target, the update is skipped without downloading, reinstalling, or rewriting `remoteclaw.json`.

When a stored integrity hash exists and the fetched artifact hash changes, RemoteClaw treats that as npm artifact drift. The interactive `remoteclaw plugins update` command prints the expected and actual hashes and asks for confirmation before proceeding. Non-interactive update helpers fail closed unless the caller supplies an explicit continuation policy.

`--dangerously-force-unsafe-install` is also accepted on `plugins update` for compatibility, but it is deprecated and no longer changes plugin update behavior. Operator `security.installPolicy` and plugin `before_install` hooks can still block updates.

Inspect

remoteclaw plugins inspect <id>
remoteclaw plugins inspect <id> --runtime
remoteclaw plugins inspect <id> --json

Inspect shows identity, load status, source, manifest capabilities, policy flags, diagnostics, install metadata, bundle capabilities, and any detected MCP or LSP server support without importing plugin runtime by default. Add --runtime to load the plugin module and include registered hooks, tools, commands, services, gateway methods, and HTTP routes. Runtime inspection reports missing plugin dependencies directly; installs and repairs stay in remoteclaw plugins install, remoteclaw plugins update, and remoteclaw doctor --fix.

Plugin-owned CLI commands are usually installed as root remoteclaw command groups, but plugins may also register nested commands under a core parent such as remoteclaw nodes. After inspect --runtime shows a command under cliCommands, run it at the listed path; for example a plugin that registers demo-git can be verified with remoteclaw demo-git ping.

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. `inspect --all` renders a fleet-wide table with shape, capability kinds, compatibility notices, bundle capabilities, and hook summary columns. `info` is an alias for `inspect`.

Doctor

remoteclaw plugins doctor

doctor reports plugin load errors, manifest/discovery diagnostics, compatibility notices, and stale plugin config references such as missing plugin slots. When the install tree and plugin config are clean it prints No plugin issues detected. If stale config remains but the install tree is otherwise healthy, the summary says so instead of implying full plugin health.

If a configured plugin is present on disk but blocked by the loader’s path-safety checks, config validation keeps the plugin entry and reports it as present but blocked. Fix the preceding blocked-plugin diagnostic, such as path ownership or world-writable permissions, instead of removing the plugins.entries.<id> or plugins.allow config.

For module-shape failures such as missing register/activate exports, rerun with REMOTECLAW_PLUGIN_LOAD_DEBUG=1 to include a compact export-shape summary in the diagnostic output.

Registry

remoteclaw plugins registry
remoteclaw plugins registry --refresh
remoteclaw plugins registry --json

The local plugin registry is RemoteClaw’s persisted cold read model for installed plugin identity, enablement, source metadata, and contribution ownership. Normal startup, provider owner lookup, channel setup classification, and plugin inventory can read it without importing plugin runtime modules.

Use plugins registry to inspect whether the persisted registry is present, current, or stale. Use --refresh to rebuild it from the persisted plugin index, config policy, and manifest/package metadata. This is a repair path, not a runtime activation path.

remoteclaw doctor --fix also repairs registry-adjacent managed npm drift: if an orphaned or recovered @remoteclaw/* package under a managed plugin npm project or the legacy flat managed npm root shadows a bundled plugin, doctor removes that stale package and rebuilds the registry so startup validates against the bundled manifest. Doctor also relinks the host remoteclaw package into managed npm plugins that declare peerDependencies.remoteclaw, so package-local runtime imports such as remoteclaw/plugin-sdk/* resolve after updates or npm repairs.

`REMOTECLAW_DISABLE_PERSISTED_PLUGIN_REGISTRY=1` is a deprecated break-glass compatibility switch for registry read failures. Prefer `plugins registry --refresh` or `remoteclaw doctor --fix`; the env fallback is only for emergency startup recovery while the migration rolls out.

Marketplace

remoteclaw plugins marketplace list <source>
remoteclaw plugins marketplace list <source> --json

Marketplace list accepts a local marketplace path, a marketplace.json path, a GitHub shorthand like owner/repo, a GitHub repo URL, or a git URL. --json prints the resolved source label plus the parsed marketplace manifest and plugin entries.

Related

• Building plugins
• CLI reference
• ClawHub