Built-In Plugins
Clawup ships with curated manifests for two plugins. No extra setup is needed beyond listing them inidentity.yaml.
These built-in manifests live in the plugin registry and include full secret definitions, validators, and lifecycle hooks. See the integration guides linked above for per-plugin setup details.
Using a Plugin
The happy path for any plugin — built-in or custom:1. Declare in identity.yaml
2. Override per-agent in clawup.yaml (optional)
3. Scaffold and deploy
clawup init, Clawup resolves each plugin’s manifest, discovers its required secrets, and adds them to .env.example. Fill in the values, then deploy.
Configuration Hierarchy
Plugin configuration merges from three levels. Later levels override earlier ones:Example: All Three Levels
Creating a Custom Plugin Manifest
When You Need One
- A third-party OpenClaw plugin not in the built-in registry
- You want to override a built-in plugin’s metadata (add hooks, change defaults)
- You’re developing a plugin and need to test the manifest locally
Where to Place It
Plugin manifests go in aplugins/ directory inside the identity:
name field inside the YAML. Files must end with .yaml or .yml.
Walkthrough: my-analytics.yaml
Here’s a step-by-step breakdown of writing a manifest for a hypothetical analytics plugin.
Required Fields
name— Must match the OpenClaw plugin package name.displayName— Shown in CLI output and prompts.installable— Settrueif the plugin needsopenclaw plugins install. Setfalsefor config-only plugins like Slack (which is built into OpenClaw).configPath— Either"plugins.entries"(most plugins) or"channels"(communication plugins like Slack).
needsFunnel
true if the plugin receives incoming webhooks. Clawup will enable Tailscale Funnel to expose a public HTTPS endpoint.
secrets
Each key in secrets is a config key passed to the plugin. The value describes how to collect and validate it.
| Field | Type | Default | Description |
|---|---|---|---|
envVar | string | — | Environment variable name (e.g., ANALYTICS_API_KEY) |
scope | "agent" | "global" | — | Per-agent or shared across the fleet |
isSecret | boolean | — | Whether to store encrypted in Pulumi config |
required | boolean | true | Deploy fails if missing |
autoResolvable | boolean | false | Can be derived by a resolve hook |
validator | string | — | Required prefix for validation (e.g., "ak_") |
instructions | object | — | { title, steps[] } — setup instructions shown to the user |
internalKeys
configTransforms
Transforms restructure config keys before writing to OpenClaw. The Slack plugin uses this to flatten nested DM config:
{ dm: { policy: "open", allowFrom: ["*"] } }, the transform produces { dmPolicy: "open", allowFrom: ["*"] }.
webhookSetup
For plugins that receive incoming webhooks:
hooks
Plugin-level lifecycle hooks. See the Lifecycle Hooks guide for the full reference.
autoResolvable: true.
defaultConfig
Lowest-priority configuration defaults:
Plugin Manifest Schema Reference
The Zod schema inpackages/core/src/schemas/plugin-manifest.ts is the source of truth. The TypeScript interface below is derived from it.
PluginManifest Fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
name | string | Yes | — | Plugin package name (e.g., "openclaw-linear") |
displayName | string | Yes | — | Human-readable name |
installable | boolean | Yes | — | Run openclaw plugins install during provisioning |
needsFunnel | boolean | No | false | Requires Tailscale Funnel for public HTTPS |
configPath | enum | Yes | — | "plugins.entries" or "channels" |
secrets | object | Yes | — | Secret definitions keyed by config key |
internalKeys | string[] | No | [] | Keys excluded from OpenClaw config |
defaultConfig | object | No | — | Lowest-priority configuration defaults |
configTransforms | array | No | [] | Config key transformations |
webhookSetup | object | No | — | Webhook endpoint configuration |
hooks | object | No | — | Lifecycle hooks (resolve, onboard, postProvision, preStart) |
PluginSecret Fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
envVar | string | Yes | — | Environment variable name |
scope | enum | Yes | — | "agent" (per-agent) or "global" (shared) |
isSecret | boolean | Yes | — | Store encrypted in Pulumi config |
required | boolean | No | true | Deploy fails if missing |
autoResolvable | boolean | No | false | Can be derived by a resolve hook |
validator | string | No | — | Required prefix for validation |
instructions | object | No | — | { title, steps[] } setup instructions |
WebhookSetup Fields
| Field | Type | Required | Description |
|---|---|---|---|
urlPath | string | Yes | URL path suffix (e.g., "/hooks/linear") |
secretKey | string | Yes | Must reference a key in secrets |
instructions | string[] | Yes | Setup steps shown to the user |
configJsonPath | string | Yes | JSON path in openclaw.json for the webhook secret |
ConfigTransform Fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
sourceKey | string | Yes | — | Key to read from raw config |
targetKeys | object | Yes | — | Mapping of source sub-keys to target keys |
removeSource | boolean | No | true | Delete source key after transform |
Plugin Resolution
Clawup resolves plugin metadata through a three-tier chain. The first match wins.1. Identity-Bundled (Highest Priority)
Manifests placed inplugins/<name>.yaml inside the identity directory. Use this to:
- Add manifests for third-party plugins
- Override built-in manifests (e.g., add hooks or change defaults)
2. Built-In Registry
ThePLUGIN_MANIFEST_REGISTRY in packages/core/src/plugin-registry.ts. Contains curated, tested manifests for openclaw-linear and slack.
3. Generic Fallback
For any plugin not found in the first two tiers, Clawup generates a minimal stub:pluginDefaults or per-agent plugins. You only need a custom manifest when you want secret management, hooks, or webhook setup.
Secrets
Discovery
Duringclawup init, Clawup resolves each plugin’s manifest, collects all secrets entries, and generates the appropriate .env.example entries. Each secret’s envVar is used as the environment variable name.
Scope
| Scope | Behavior | Example |
|---|---|---|
agent | Each agent gets its own value. Env var is prefixed with the agent role (e.g., ENG_LINEAR_API_KEY). | API keys, bot tokens |
global | Shared across all agents. Single env var. | Shared webhooks, team-wide tokens |
Auto-Resolution
Secrets markedautoResolvable: true can be derived at deploy time by a resolve hook. The hook script runs on your machine during clawup deploy, with all other secrets available as environment variables. The script’s stdout becomes the secret’s value.
Validation
Thevalidator field specifies a required prefix. During clawup secrets set and deploy, values are checked against this prefix:
Setup Instructions
Theinstructions field provides step-by-step guidance shown during clawup secrets set:
Secret Flow
Complete Examples
Minimal Manifest
The smallest valid plugin manifest — just name, installable flag, and config path:Full-Featured Manifest
All fields, with hooks, webhook setup, and config transforms:examples/plugin-manifests/ directory for the built-in Linear and Slack manifests as YAML references.
Tips
- Test config locally — run
clawup config show --jsonto inspect the resolved plugin configuration before deploying. - Override built-in manifests — place a same-named file in
plugins/(e.g.,plugins/openclaw-linear.yaml) to override the built-in manifest with your own hooks or defaults. - Version control manifests — keep plugin manifests in the identity repo alongside
identity.yamlso they’re versioned together. - Use
internalKeysfor routing metadata (likeagentId) that Clawup needs but the OpenClaw plugin doesn’t. - Start without a manifest — the generic fallback means any plugin works immediately. Add a manifest later when you need secrets, hooks, or webhook setup.
- Check the Zod schema —
packages/core/src/schemas/plugin-manifest.tsis the source of truth. If the docs and schema disagree, the schema wins.