OpenClaw Plugin System: Claude, Codex, and Cursor Integration (2026) | OpenClaw DC

The OpenClaw plugin system lets you discover, install, and run skill bundles from Claude Code, Codex, and Cursor inside your OpenClaw agent. Version 3.22 completely rebuilt this system. Plugins now handle all external bundle integration while OpenClaw hooks stay focused on visibility, controls, and guardrails. When you install a plugin, OpenClaw reads the bundle manifest, maps each bundled skill into a native OpenClaw skill, and applies any settings.json defaults the bundle ships with. The result is a single command to pull in a full tool suite from another agent framework and have it work natively inside OpenClaw.

What changed in v3.22

Before v3.22, plugin support was a set of loosely connected scripts. Installing a Claude Code bundle meant manually copying files, editing config, and hoping the skill names did not collide. Hook packs and plugins lived in the same layer, which made it unclear what ran at what stage.

Version 3.22 drew a clean line. Hooks handle visibility and controls: logging every tool call, enforcing approval gates, applying spending caps. Plugins handle external integrations: discovering packages, resolving dependencies, mapping foreign skill formats into OpenClaw skills. Hook-pack installs now route through the plugin system instead of being a separate mechanism. This separation made both layers simpler and more predictable.

The rebuild also included Windows security patches. A vulnerability allowed SMB credential leaks on Windows machines when plugins loaded resources from UNC paths. Version 3.22 blocks that vector entirely by sanitizing all file paths before plugin resolution. For a broader security overview, see our OpenClaw security checklist.

How plugins work

The plugin lifecycle has three stages: discover, install, and map.

Discover. OpenClaw searches configured registries for plugin packages. By default it checks the ClawHub registry, but you can add custom registries pointing to private npm feeds, GitHub releases, or local directories.

Install. When you install a plugin, OpenClaw downloads the package, validates its manifest signature, and places it in the plugins directory. If the package includes a settings.json, those defaults are merged into your OpenClaw config. Existing settings are never overwritten. Only missing keys get filled in.

Map. Each skill defined in the bundle manifest gets mapped to an OpenClaw skill entry. The mapping preserves the original skill name, description, and trigger conditions. If a bundle skill conflicts with an existing skill name, OpenClaw prefixes it with the plugin name to avoid collisions. You can rename or disable mapped skills after installation.

Claude Code bundle integration

Claude Code ships bundles as directories containing a manifest and one or more SKILL.md files. OpenClaw reads the Claude Code manifest format natively. When you install a Claude Code bundle as a plugin, each skill file becomes a first-class OpenClaw skill with all the same trigger conditions, tool permissions, and rule constraints the original author defined.

Settings defaults from the Claude Code bundle, like model preferences, tool access lists, and context window limits, are applied through the settings.json merge process. If the bundle expects access to specific tools like bash or browser, OpenClaw checks your permissions config and warns you if a required tool is disabled.

To install a Claude Code bundle:

openclaw plugin install claude-code/my-bundle

OpenClaw resolves the package from the registry, maps the skills, and applies defaults. You can verify with:

openclaw plugin list

For more on writing compatible skills, see our guide on how to build an OpenClaw skill.

Codex bundle integration

OpenAI Codex bundles follow a different manifest format, but the plugin system handles the translation. Codex bundles typically define tools as JSON schemas with execution targets. OpenClaw maps each Codex tool definition into a skill wrapper that preserves the input schema and execution behavior.

The key difference from Claude Code bundles is that Codex bundles often ship with execution scripts rather than natural language instructions. OpenClaw wraps these scripts in a skill envelope that adds logging, approval gates, and sandbox enforcement. The original script runs inside the same sandbox as any other OpenClaw tool call.

openclaw plugin install codex/code-review-pack

After installation, the Codex tools appear alongside your other skills in the dashboard and respond to the same trigger patterns.

Cursor bundle integration

Cursor extensions package their capabilities as rule sets and tool configurations. The OpenClaw plugin system reads Cursor bundle manifests and converts each rule set into a corresponding OpenClaw skill. Cursor bundles tend to be editor-centric, so the mapping focuses on code analysis, refactoring, and file manipulation skills.

If a Cursor bundle references editor-specific APIs that OpenClaw does not support, those skills are marked as incompatible during installation. OpenClaw logs which skills were skipped and why, so you can decide whether to find alternatives or request support.

openclaw plugin install cursor/refactor-suite

Compatible skills from the Cursor bundle work identically to native OpenClaw skills once installed.

How to install a plugin

The core commands cover the full lifecycle:

openclaw plugin search "code review"       # Find plugins by keyword
openclaw plugin install author/package     # Install from registry
openclaw plugin list                        # Show installed plugins
openclaw plugin info author/package        # View details and mapped skills
openclaw plugin update author/package      # Update to latest version
openclaw plugin remove author/package      # Uninstall and clean up

You can also install from a local directory during development:

openclaw plugin install ./my-local-plugin

Local installs skip signature validation but still run the mapping and settings merge steps. This is useful when building and testing your own bundles before publishing.

Security: what plugins can and cannot access

Plugins run inside the OpenClaw sandbox. They cannot read environment variables, access credentials, or touch files outside the project directory unless you explicitly grant access through the permissions config. Every tool call made by a plugin-mapped skill goes through the same approval and logging pipeline as native skills.

Plugins cannot modify OpenClaw core files, alter hook behavior, or escalate their own permissions. The settings.json merge only fills in missing keys. A plugin cannot overwrite your existing rate limits, spending caps, or tool restrictions.

The v3.22 Windows security patch addressed a specific attack where a malicious plugin could reference a UNC path to trigger SMB authentication, leaking Windows credentials to an attacker-controlled server. That vector is now blocked at the path sanitization layer before any file I/O occurs.

For a full walkthrough of securing your OpenClaw installation, read our security checklist.

What comes next

The plugin system in v3.22 laid the foundation. Version 3.24 built on it with the skills and tool management UI, making it easier to browse, toggle, and configure plugin-mapped skills from the dashboard instead of the CLI. Future releases will expand registry federation and add plugin dependency resolution across registries.

If you are building tools for Claude Code, Codex, or Cursor and want them to work inside OpenClaw, the plugin manifest format is documented in the ClawHub developer guide. Write the bundle once and it runs everywhere OpenClaw does.

Need help setting up plugins for your team? Book a Call and we will walk through your integration.