tencent cloud

Plugin API Reference

Download
Focus Mode
Font Size
Last updated: 2026-09-30 18:41:47
AI-Translated
Note:
A complete technical reference for the CodeBuddy plugin system, including component specifications, CLI commands, and development tools.
Plugins are self-contained component directories used to extend the custom features of CodeBuddy. Plugin components include Skills, Agents, Hooks, MCP servers, and LSP servers.

1. Plugin Component Reference

1. Skills

Plugins extend CodeBuddy by adding skills, creating /name shortcuts for users or AI assistants to invoke.
Location: the skills/ or commands/ directory in the plugin root directory
File Format: A skill is a directory containing SKILL.md. A command is a simple Markdown file.
Directory Structure:
skills/
├── pdf-processor/
│ ├── SKILL.md
│ ├── reference.md (Optional)
│ └── scripts/ (Optional)
└── code-reviewer/
└── SKILL.md
Integration Behavior:
Skills and commands are automatically discovered when a plugin is installed.
The AI assistant can invoke them automatically based on the task context.
A skill can contain auxiliary files and scripts.
For details, see Skills.

2. Agents

A plugin can provide specialized subagents for specific tasks, and the AI assistant can invoke them automatically when appropriate.
Location: the agents/ directory in the plugin root directory
Format: a Markdown file that describes the agent's capabilities
Frontmatter Configuration:
---
name: agent-name
description: The agent's expertise and when it should be invoked
model: sonnet
effort: medium
maxTurns: 20
disallowedTools: Write, Edit
---

The detailed system prompt for the agent, describing its role, expertise, and behavior.
Plugin agents support the following frontmatter fields: name, description, model, effort, maxTurns, tools, disallowedTools, skills, memory, background, and isolation. The only valid value for isolation is "worktree". For security reasons, plugin agents do not support the hooks, mcpServers, and permissionMode fields.
Integration Method:
The agent appears on the /agents page.
The AI assistant can automatically invoke agents based on the task context.
Users can also invoke agents manually.
Plugin agents work together with built-in agents.
For details, see Subagents.

3. Hooks

A plugin can provide event handlers that automatically respond to CodeBuddy events.
Location: the plugin's root hooks/hooks.json file, or inline configuration in plugin.json
Format: a JSON configuration that contains event matchers and actions
Configuration example:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "${CODEBUDDY_PLUGIN_ROOT}/scripts/format-code.sh"
}
]
}
]
}
}
Available events:
Plugin hooks respond to the same lifecycle events as user-defined hooks:
Event
Trigger Timing
SessionStart
When a session starts or resumes
UserPromptSubmit
When a user submits a prompt and before AI processes it
PreToolUse
Before a tool call is executed, it can be blocked.
PermissionRequest
When a permission dialog appears
PermissionDenied
When a tool call is rejected by the automatic mode classifier, return {retry: true} to inform the model that it can retry.
PostToolUse
After the tool is successfully called
PostToolUseFailure
After tool call failure
Notification
When CodeBuddy sends a notification
SubagentStart
When a subagent starts
SubagentStop
When a subagent completes
TaskCreated
When a task is created through TaskCreate
TaskCompleted
When a task is marked as completed
Stop
When AI completes a response
StopFailure
When a turn ends due to an API error, output and exit code are ignored.
TeammateIdle
When a teammate is about to become idle
InstructionsLoaded
When CODEBUDDY.md or .codebuddy/rules/*.md files are loaded into the context
ConfigChange
When a configuration file changes during a session
CwdChanged
When the working directory changes (for example, when AI runs the cd command)
FileChanged
When a monitored file changes on disk. The matcher field specifies the file name to monitor.
WorktreeCreate
When a worktree is created through --worktree or isolation: "worktree"
WorktreeRemove
When a worktree is removed (when a session exits or a subagent completes)
PreCompact
Before context compression
PostCompact
After context compression is completed
Elicitation
When an MCP server requests user input during a tool call
ElicitationResult
After the user responds to the MCP elicitation and before the response is sent back to the server
SessionEnd
When a session terminates
Hook type:
command: Executes a shell command or script.
http: Sends the event JSON as a POST request to a URL.
prompt: Uses an LLM to evaluate the prompt (use the $ARGUMENTS placeholder to obtain context).
agent: Runs an agent validator with tools for complex validation tasks.
Differences from Skill / Agent frontmatter hooks:
A plugin can carry hooks through two different paths:
Path
Scope
Security Gate
hooks/hooks.json (described in this section)
Entire session (when the plugin is enabled)
Not restricted by allowUntrustedFrontmatterHooks; takes effect once the plugin is enabled.
agents/*.md or hooks frontmatter in skills/SKILL.md
Only within the lifecycle of the subagent / fork skill
Restricted by the allowUntrustedFrontmatterHooks gate and denied by default. Users need to explicitly enable it in settings.json.
Because frontmatter hooks are blocked by a security gate, if a Skill or Agent distributed by a plugin depends on frontmatter hooks to work properly, the plugin README should clearly instruct users to enable the allowUntrustedFrontmatterHooks setting. For details, see Hook Reference Guide - Frontmatter Hooks.

4. MCP Servers

A plugin can bundle a Model Context Protocol (MCP) server to connect CodeBuddy with external tools and services.
Location: the plugin's root .mcp.json file, or inline configuration in plugin.json
Format: Standard MCP server configuration
Configuration example:
{
"mcpServers": {
"plugin-database": {
"command": "${CODEBUDDY_PLUGIN_ROOT}/servers/db-server",
"args": ["--config", "${CODEBUDDY_PLUGIN_ROOT}/config.json"],
"env": {
"DB_PATH": "${CODEBUDDY_PLUGIN_ROOT}/data"
}
},
"plugin-api-client": {
"command": "npx",
"args": ["@company/mcp-server", "--plugin-mode"],
"cwd": "${CODEBUDDY_PLUGIN_ROOT}"
}
}
}
Integration Behavior:
Automatically start the MCP server when the plugin is enabled.
The server appears in the toolkit as a standard MCP tool.
Server features integrate seamlessly with existing tools.
Plugin servers can be configured independently of user MCP servers.

5. LSP Servers

Note:
Need to use an LSP plugin? You can install one from the official marketplace by searching for "lsp" in the /plugin Discover tab. This section describes how to create an LSP plugin for a language that is not covered by the official marketplace.
A plugin can provide a Language Server Protocol (LSP) server to provide real-time code intelligence support for AI assistants working on a codebase.
LSP Integration Provides:
Instant Diagnostics: The AI assistant sees errors and warnings immediately after each edit.
Code Navigation: Go to definition, find references, and hover information.
Language Awareness: Type information and documentation for code symbols.
Location: the plugin's root .lsp.json file, or inline configuration in plugin.json
Format: a JSON configuration that maps language server names to their configurations
.lsp.json File Format:
{
"go": {
"command": "gopls",
"args": ["serve"],
"extensionToLanguage": {
".go": "go"
}
}
}
Configure inline in plugin.json:
{
"name": "my-plugin",
"lspServers": {
"go": {
"command": "gopls",
"args": ["serve"],
"extensionToLanguage": {
".go": "go"
}
}
}
}
Required Fields:
Field
Description
command
LSP binary file to be executed (must be in PATH)
extensionToLanguage
Map file extensions to language identifiers.
Optional Fields:
Field
Description
args
Command-line arguments for the LSP server
transport
Transport mode: stdio (default) or socket
env
Environment variables set when the server is started
initializationOptions
Options passed to the server during initialization
settings
Settings passed through workspace/didChangeConfiguration
workspaceFolder
Workspace folder path of the server
startupTimeout
Maximum time to wait for the server to start in milliseconds
shutdownTimeout
Maximum time to wait for graceful shutdown in milliseconds
restartOnCrash
Restart automatically or not when the server crashes
maxRestarts
Maximum restart attempts before the system gives up
Warning:
You must install the language server binary separately. The LSP plugin configures how CodeBuddy connects to the language server, but does not include the server itself. If you see the Executable not found in $PATH error in the /plugin Errors tag, install the required binary for your language.
Available LSP Plugins:
Plugins
Language Server
Installation Command
pyright-lsp
Pyright (Python)
pip install pyright or npm install -g pyright
typescript-lsp
TypeScript Language Server
npm install -g typescript-language-server typescript
rust-lsp
rust-analyzer
Install the language server first, and then install the plugin from the marketplace.

2. Plugin Installation Scope

When installing a plugin, select a scope to determine where the plugin is available:
Scope
Settings File
Scenario
user
~/.codebuddy/settings.json
Personal plugin, available in all projects (default)
project
.codebuddy/settings.json
Team plugin, shared through version control
local
.codebuddy/settings.local.json
Project-specific plugin, ignored by gitignore.
managed
Managed settings
Managed plugin (read-only, update only)
Plugins use the same scope system as other CodeBuddy configurations. For details, see Settings.

3. Plugin Manifest Structure (plugin.json)

The .codebuddy-plugin/plugin.json file (or .workbuddy-plugin/plugin.json, .claude-plugin/plugin.json) defines the plugin's metadata and configuration. This section documents all supported fields and options.
The manifest is optional. If the manifest is omitted, CodeBuddy automatically discovers components in their default locations and derives the plugin name from the directory name. Use a manifest when you need to provide metadata or customize component paths.

Complete Structure Example

{
"name": "plugin-name",
"version": "1.2.0",
"description": "A brief description of the plugin",
"author": {
"name": "Author name",
"email": "[email protected]",
"url": "https://github.com/author"
},
"homepage": "https://docs.example.com/plugin",
"repository": "https://github.com/author/plugin",
"license": "MIT",
"keywords": ["keyword1", "keyword2"],
"commands": ["./custom/commands/special.md"],
"agents": "./custom/agents/",
"skills": "./custom/skills/",
"hooks": "./config/hooks.json",
"mcpServers": "./mcp-config.json",
"outputStyles": "./styles/",
"lspServers": "./.lsp.json",
"defaultEnabled": false,
"dependencies": [
"audit-logger",
{ "name": "secrets-vault", "version": "~2.1.0" }
],
"experimental": {
"themes": "./themes/",
"monitors": "./monitors/monitors.json"
}
}

Required Fields

If a manifest is included, name is the only required field.
Field
Type
Description
Example
name
string
Unique identifier (kebab-case, no spaces)
"deployment-tools"
This name is used for component namespacing. For example, in the UI, the agent agent-creator of the plugin plugin-dev is displayed as plugin-dev:agent-creator.

Metadata Field

Field
Type
Description
Example
version
string
Semantic version. If it is also set in the marketplace entry, plugin.json takes precedence. Set it in only one place.
"2.1.0"
description
string
Brief description of the plugin's purpose
"Deployment automation tool"
author
object
Author information
{"name": "Dev team", "email": "[email protected]"}
homepage
string
Documentation URL
"https://docs.example.com"
repository
string
Source code URL
"https://github.com/user/plugin"
license
string
License identifier
"MIT", "Apache-2.0"
keywords
array
Discovery tags
["deployment", "ci-cd"]
defaultEnabled
boolean
Whether to enable when not explicitly set. Default: true.
false
dependencies
array
Other plugins that the current plugin depends on. You can declare semver ranges and marketplace.
[{"name":"helper","version":"^2.0.0"}]

Component Path Field

Field
Type
Description
Example
commands
string | array
Custom command file or directory (replaces the default commands/)
"./custom/cmd.md" or ["./cmd1.md"]
agents
string | array
Custom agent file (replaces the default agents/)
"./custom/agents/reviewer.md"
skills
string | array
Custom skill directory (replaces the default skills/)
"./custom/skills/"
hooks
string | array | object
Hook configuration path or inline configuration
"./my-extra-hooks.json"
mcpServers
string | array | object
MCP configuration path or inline configuration
"./my-extra-mcp-config.json"
outputStyles
string | array
Custom output style file or directory (replaces the default output-styles/)
"./styles/"
experimental.themes
string | array
Claude experimental field; CodeBuddy currently only recognizes it and does not load it into the runtime.
"./themes/"
experimental.monitors
string | array
Claude experimental field; CodeBuddy currently only recognizes it and does not start the background monitor.
"./monitors/monitors.json"
lspServers
string | array | object
LSP configuration path or inline configuration
"./.lsp.json"
userConfig
object
Prompts users to configure the value when enabled. For details, see User Configuration.
experimental.themes.
channels
array
Channel declaration for message injection. For details, see Channels.
experimental.themes.

Enabled by Default

defaultEnabled: false keeps newly installed plugins disabled. Existing enabledPlugins settings take precedence over this default value, so upgrading or reinstalling does not change the state that users have explicitly selected. If a plugin is a dependency of an enabled plugin, the dependency relationship takes precedence, and CodeBuddy enables it explicitly.

Plugin Dependencies

dependencies can be declared in both plugin.json and marketplace plugin entries, and the declarations are merged. String dependencies are resolved to the marketplace where they are declared. Objects support the following fields:
Field
Required
Description
name
Yes
Plugin name
version
No
Node semver range, for example, ~2.1.0, ^2.0, >=1.4
marketplace
No
marketplace where the dependency resides. If it is omitted, the declarer's marketplace is used.
Automatic installation across marketplaces is blocked by default. You must explicitly grant authorization in the marketplace.json file of the marketplace to which the root plugin belongs:
{
"name": "acme-tools",
"allowCrossMarketplaceDependenciesOn": ["acme-shared"],
"plugins": []
}
Only the allowlist of the root marketplace takes effect, and trust is not propagated. Cross-marketplace dependencies that users have manually installed and whose versions meet the requirements can be reused directly.
Version constraints are resolved through Git tags. Publishers name tags using {plugin-name}--v{version}, for example secrets-vault--v2.1.3. CodeBuddy merges the ranges of all enabled plugins for the same dependency and selects the highest version that satisfies the intersection. The tag semver is recorded in resolvedVersion. The cache directory uses the declared version plus a 12-character commit SHA suffix to prevent forcibly moved tags from reusing stale content.
Installing a plugin automatically installs its complete transitive dependencies. Enabling a plugin only transitively enables dependencies that are already installed. If dependencies are missing, the plugin fails to enable. Disabling or uninstalling a plugin that is still required by other enabled plugins is blocked.
Dependencies that are automatically installed are marked as auto: true in installed_plugins.json. A regular uninstall retains these dependencies. Only plugin prune or plugin uninstall --prune removes auto dependencies that are no longer required by any manually installed plugin. Explicitly installing an auto dependency promotes it to a manual installation, after which it is not pruned.

User Configuration

The userConfig field declares values that CodeBuddy prompts users to enter when the plugin is enabled. Use this instead of requiring users to manually edit settings.json.
{
"userConfig": {
"api_endpoint": {
"description": "Your team's API endpoint"
"sensitive": false
},
"api_token": {
"description": "API authentication token"
"sensitive": true
}
}
}
Keys must be valid identifiers. Each value can be substituted as ${user_config.KEY} in MCP and LSP server configurations and hook commands, and (for non-sensitive values only) in skills, commands, and agent content. Values are also exported to plugin subprocesses as the CLAUDE_PLUGIN_OPTION_<KEY> and CODEBUDDY_PLUGIN_OPTION_<KEY> environment variables. Non-alphabetic, non-numeric, or non-underscore characters in environment variable names are replaced with _ and then converted to uppercase.
Non-sensitive values are stored in pluginConfigs[<plugin-id>].options in settings.json. Sensitive values are stored in the system keychain, or in ~/.codebuddy/.credentials.json if the keychain is unavailable. Keychain storage is shared with OAuth tokens and has a total limit of approximately 2 KB, so sensitive values should be kept small.

Channel

The channels field allows a plugin to declare one or more message channels for injecting content into conversations. Each channel is bound to an MCP server provided by the plugin.
{
"channels": [
{
"server": "telegram",
"userConfig": {
"bot_token": { "description": "Telegram bot token", "sensitive": true },
"owner_id": { "description": "Your Telegram user ID", "sensitive": false }
}
}
]
}
The server field is required and must match a key in the plugin's mcpServers. The optional per-channel userConfig uses the same schema as the top level, allowing prompts for a bot token or owner ID when the plugin is enabled.

Path Behavior Rules

For commands, agents, skills, and outputStyles, custom paths replace the default directories. If the manifest specifies commands, the default commands/ directory is not scanned. Hooks, MCP servers, and LSP servers have different semantics for handling multiple sources.
All paths must be relative to the plugin root directory and start with ./.
Components in custom paths use the same naming and namespace rules.
You can specify multiple paths as an array.
To keep the default directory and add more paths, include the default directory in the array: "commands": ["./commands/", "./extras/deploy.md"]
Path examples:
{
"commands": [
"./specialized/deploy.md",
"./utilities/batch-process.md"
],
"agents": [
"./custom-agents/reviewer.md",
"./custom-agents/tester.md"
]
}

Environment Variable

CodeBuddy provides three Claude Code-compatible path variables. They are substituted inline in skills, commands, and agent content, hook configurations, and MCP or LSP server configurations, and are also exported as environment variables to hook, MCP, and LSP subprocesses. Each CLAUDE_* name has a corresponding CODEBUDDY_* alias.
${CODEBUDDY_PLUGIN_ROOT}: The absolute path to the plugin installation directory. It is used to reference scripts, binaries, and configuration files bundled with the plugin. This path changes when the plugin is updated, so files written here are not preserved after updates.
Compatibility: The ${CLAUDE_PLUGIN_ROOT} variable name is also supported for compatibility with Claude Code plugins.
${CODEBUDDY_PLUGIN_DATA}: The persistent directory for plugin state, which is preserved after updates. It is used for installed dependencies (such as node_modules or Python virtual environments), generated code, caches, and any files that need to persist across plugin versions. The directory is automatically created when the placeholder is first referenced or exported to a plugin subprocess.
Compatibility: The ${CLAUDE_PLUGIN_DATA} variable name is also supported.
${CODEBUDDY_PROJECT_DIR}: The root directory of the current workspace. It is used by plugin scripts to locate the user's project and should not be used to write the plugin's own persistent state.
Compatibility: The ${CLAUDE_PROJECT_DIR} variable name is also supported.
Plugin subprocesses also receive the following option environment variables:
CLAUDE_PLUGIN_OPTION_<KEY>: The standard Claude Code name
CODEBUDDY_PLUGIN_OPTION_<KEY>: The CodeBuddy alias
PLUGIN_OPT_<KEY>: A compatibility name reserved for existing CodeBuddy plugins
{
"hooks": {
"PostToolUse": [
{
"hooks": [
{
"type": "command",
"command": "${CODEBUDDY_PLUGIN_ROOT}/scripts/process.sh"
}
]
}
]
}
}

Persistent Data Directory

The ${CODEBUDDY_PLUGIN_DATA} directory resolves to ~/.codebuddy/plugins/data/{id}/, where {id} is the plugin identifier with any characters other than a-z, A-Z, 0-9, _, and - replaced by -. For example, a plugin installed as formatter@my-marketplace has the directory ~/.codebuddy/plugins/data/formatter-my-marketplace/.
A common practice is to install language dependencies once and reuse them across sessions and plugin updates. Because the data directory outlives any single plugin version, checking only for directory existence cannot detect when an update has changed the plugin's dependency manifest. The recommended pattern is to compare the bundled manifest with the copy in the data directory and reinstall when they differ.
The following SessionStart hook installs node_modules on first run and reinstalls them when a plugin update includes changes to package.json:
{
"hooks": {
"SessionStart": [
{
"hooks": [
{
"type": "command",
"command": "diff -q \\"${CODEBUDDY_PLUGIN_ROOT}/package.json\\" \\"${CODEBUDDY_PLUGIN_DATA}/package.json\\" >/dev/null 2>&1 || (cd \\"${CODEBUDDY_PLUGIN_DATA}\\" && cp \\"${CODEBUDDY_PLUGIN_ROOT}/package.json\\" . && npm install) || rm -f \\"${CODEBUDDY_PLUGIN_DATA}/package.json\\""
}
]
}
]
}
}
diff exits with a non-zero status when the stored copy is missing or differs from the bundled copy, covering both first runs and updates with dependency changes. If npm install fails, the trailing rm removes the copied manifest so that the next session can retry.
Scripts bundled in ${CODEBUDDY_PLUGIN_ROOT} can run against the persisted node_modules:
{
"mcpServers": {
"routines": {
"command": "node",
"args": ["${CODEBUDDY_PLUGIN_ROOT}/server.js"],
"env": {
"NODE_PATH": "${CODEBUDDY_PLUGIN_DATA}/node_modules"
}
}
}
}
When the last installation scope of a plugin is uninstalled, the data directory is automatically deleted. If the same plugin is still installed in other scopes, the data directory is retained. The CLI deletes it by default, and passing --keep-data retains it. plugin prune deletes the data directories of orphaned automatic dependencies.

4. Plugin Cache and File Parsing

There are two ways to specify a plugin:
Valid only for the session when it is passed through codebuddy --plugin-dir
Installed from the marketplace, it applies to future sessions.
For security and verification purposes, CodeBuddy copies marketplace plugins to the user's local versioned plugin cache (~/.codebuddy/plugins/cache/<marketplace>/<plugin>/<version>) instead of using them in place. Marketplace source code remains in ~/.codebuddy/plugins/marketplaces/<marketplace>, and understanding this behavior is important for developing plugins that reference external files.

Path Traversal Restrictions

Installed plugins cannot reference files outside their directory. Paths that traverse outside the plugin root, such as ../shared-utils, will not work after installation because those external files are not copied to the cache.

Using External Dependencies

If a plugin needs to access shared files in the same marketplace, you can create symbolic links in the plugin directory. During cache copying, they are processed according to their target locations:
Pointing inside the plugin's own directory: retained as a relative symbolic link.
Pointing to another location in the same marketplace: dereference and copy the target content.
Pointing outside the marketplace: skip the symbolic link.
# Inside the plugin directory
ln -s ../../shared-plugin/skills/foo ./skills/foo
This allows files to be shared within the marketplace while preventing plugins from bringing arbitrary host files into the cache.

5. Plugin Directory Structure

Standard Plugin Layout

A complete plugin follows this structure:
enterprise-plugin/
├── .codebuddy-plugin/ # Metadata directory (optional)
│ └── plugin.json # Plugin manifest
├── commands/ # Default command location
│ ├── status.md
│ └── logs.md
├── agents/ # Default agent location
│ ├── security-reviewer.md
│ ├── performance-tester.md
│ └── compliance-checker.md
├── skills/ # Agent skills
│ ├── code-reviewer/
│ │ └── SKILL.md
│ └── pdf-processor/
│ ├── SKILL.md
│ └── scripts/
├── output-styles/ # Output style definitions
│ └── terse.md
├── themes/ # Claude standard theme definitions; currently recognized but not loaded
│ └── dracula.json
├── monitors/ # Claude standard background monitors; currently recognized but not started
│ └── monitors.json
├── hooks/ # Hook configuration
│ ├── hooks.json # Main hook configuration
│ └── security-hooks.json # Additional hooks
├── bin/ # Plugin executables, added to PATH
│ └── my-tool # Can be invoked as a bare command in the Bash tool
├── settings.json # Default plugin settings
├── .mcp.json # MCP server definition
├── .lsp.json # LSP server configuration
├── scripts/ # Hooks and utility scripts
│ ├── security-scan.sh
│ ├── format-code.py
│ └── deploy.js
├── LICENSE # License file
└── CHANGELOG.md # Version history
Note:
The .codebuddy-plugin/ directory contains the plugin.json file. All other directories (commands/, agents/, skills/, output-styles/, themes/, monitors/, hooks/) must be located at the plugin root, not inside .codebuddy-plugin/. The .workbuddy-plugin/ and .claude-plugin/ directories are also supported.

File Location Reference

Component
Default Location
Purpose
Manifest
.codebuddy-plugin/plugin.json
Plugin metadata and configuration (optional)
Commands
commands/
Skill Markdown files (legacy; new skills use skills/)
Agents
agents/
Subagent Markdown files
Skills
skills/
Skills with the <name>/SKILL.md structure
Output styles
output-styles/
Output style definitions
Themes
themes/
Claude standard field; CodeBuddy currently only recognizes it and does not load it into the runtime.
Monitors
monitors/monitors.json
Claude standard field; CodeBuddy currently only recognizes it and does not start the background monitor.
Hooks
hooks/hooks.json
Hook configuration
MCP servers
.mcp.json
MCP server definitions
LSP servers
.lsp.json
Language server configuration
Executables
bin/
Executable files added to the Bash tool PATH. When the plugin is enabled, files in this directory can be invoked as bare commands in any Bash tool call.
Settings
settings.json
Default plugin configuration. The current runtime applies agent; subagentStatusLine is only recognized and retained.

6. CLI Command Reference

CodeBuddy provides CLI commands for non-interactive plugin management, suitable for scripting and automation.

plugin install

Install plugins from the available marketplace.
codebuddy plugin install <plugin> [options]
Parameters:
<plugin>: The plugin name or plugin-name@marketplace-name (specifies a specific marketplace)
Options:
Option
Description
Default Value
-s, --scope <scope>
Installation scope: user, project, or local
user
-h, --help
Display command help
-
The scope determines which settings file the installed plugin is added to. For example, --scope project writes to enabledPlugins in .codebuddy/settings.json, making the plugin available to anyone who clones the project repository.
Example:
# Install to user scope (default)
codebuddy plugin install formatter@my-marketplace

# Install to project scope (shared with the team)
codebuddy plugin install formatter@my-marketplace --scope project

# Install to local scope (gitignored)
codebuddy plugin install formatter@my-marketplace --scope local

plugin uninstall

Remove installed plugins.
codebuddy plugin uninstall <plugin> [options]
Parameters:
<plugin>: The plugin name or plugin-name@marketplace-name
Options:
Option
Description
Default Value
-s, --scope <scope>
Uninstall from the specified scope: user, project, or local
user
--keep-data
Keep the persistent data directory of the plugin.
-
--prune
Also clean up auto dependencies that are no longer needed in this scope.
-
-y, --yes
Skip --prune confirmation; must be specified when stdin or stdout is not a TTY.
-
-h, --help
Display command help.
-
Aliases: remove, rm
By default, the plugin's ${CODEBUDDY_PLUGIN_DATA} directory is also deleted when the plugin is uninstalled from the last remaining scope. Use --keep-data to retain it, for example when reinstalling after testing a new version.

plugin prune

Remove auto dependencies in the specified scope that are no longer required by any manually installed plugin.
codebuddy plugin prune [options]
Option
Description
Default Value
-s, --scope <scope>
Cleanup scope: user, project, or local
user
--dry-run
List only the plugins to be cleaned up without modifying settings or the registry.
-
-y, --yes
Skip confirmation; list only candidates when stdin or stdout is not a TTY and no option is specified.
-
-h, --help
Display command help.
-

plugin enable

Enable a disabled plugin.
codebuddy plugin enable <plugin> [options]
Parameters:
<plugin>: The plugin name or plugin-name@marketplace-name
Options:
Option
Description
Default Value
-s, --scope <scope>
Enabled scope: user, project, or local
Automatically detect the current installation scope.
-h, --help
Display command help.
-

plugin disable

Disable a plugin without uninstalling it.
codebuddy plugin disable <plugin> [options]
Parameters:
<plugin>: The plugin name or plugin-name@marketplace-name
Options:
Option
Description
Default Value
-s, --scope <scope>
Disabled scope: user, project, or local
Automatically detect the current installation scope.
-h, --help
Display command help.
-

plugin update

Update the plugin to the latest version.
codebuddy plugin update <plugin> [options]
Parameters:
<plugin>: The plugin name or plugin-name@marketplace-name
Options:
Option
Description
Default Value
-s, --scope <scope>
Update scope: user, project, local, or managed
user
-h, --help
Display command help.
-

plugin list

List installed plugins along with their versions, marketplaces, enablement status, and dependency errors. --json can be used for script-based reading of dependencyErrors.
codebuddy plugin list --json

Marketplace Management

# Add a marketplace.
codebuddy plugin marketplace add <source> [--name <name>]

# List marketplaces.
codebuddy plugin marketplace list

# Update a marketplace.
codebuddy plugin marketplace update <name>

# Delete a marketplace.
codebuddy plugin marketplace remove <name>
Marketplace source format:
# Local directory.
codebuddy plugin marketplace add /path/to/marketplace

# GitHub shorthand
codebuddy plugin marketplace add owner/repo

# Git URL
codebuddy plugin marketplace add https://github.com/owner/repo.git

# HTTP URL (marketplace.json)
codebuddy plugin marketplace add https://example.com/marketplace.json

7. Debugging and Development Tools

Debugging Commands

Use codebuddy --debug to view plugin loading details:
Display content:
Which plugins are being loaded?
Any errors in the plugin manifest.
Command, agent, and hook registration.
MCP server initialization.

Troubleshooting Common Issues

Issue
Reason
Solution
Plugin not loaded.
Invalid plugin.json
Run codebuddy plugin validate or /plugin validate to check plugin.json, skill/agent/command frontmatter, and hooks/hooks.json for syntax and schema errors.
Command not displayed.
Incorrect directory structure
Ensure commands/ is in the plugin root directory, not inside .codebuddy-plugin/
Hook not triggered.
Script is not executable.
Run chmod +x script.sh
MCP server failure.
Missing ${CODEBUDDY_PLUGIN_ROOT}
Use this variable for all plugin paths.
Path error
Used an absolute path.
All paths must be relative and start with ./.
LSP Executable not found in $PATH
Language server not installed.
Install the binary file (for example, npm install -g typescript-language-server typescript).

Common Error Messages

Manifest validation error:

Invalid JSON syntax: Unexpected token } in JSON at position 142: Check for missing commas, extra commas, or unquoted strings.
Plugin has an invalid manifest file at .codebuddy-plugin/plugin.json. Validation errors: name: Required: Missing required field.
Plugin has a corrupt manifest file at .codebuddy-plugin/plugin.json. JSON parse error: ...: JSON syntax error.
Plugin loading errors:
Warning: No commands found in plugin my-plugin custom directory: ./cmds. Expected .md files or SKILL.md in subdirectories.: The command path exists but contains no valid command files.
Plugin directory not found at path: ./plugins/my-plugin. Check that the marketplace entry has the correct path.: The source path in marketplace.json points to a directory that does not exist.
Plugin my-plugin has conflicting manifests: both plugin.json and marketplace entry specify components.: Remove duplicate component definitions or remove strict: false from the marketplace entry.

Hook Troubleshooting

Hook script was not executed:
1. Check whether the script is executable: chmod +x ./scripts/your-script.sh
2. Verify the shebang line: the first line should be #!/bin/bash or #!/usr/bin/env bash.
3. Check whether the path uses ${CODEBUDDY_PLUGIN_ROOT}: "command": "${CODEBUDDY_PLUGIN_ROOT}/scripts/your-script.sh"
4. Manual test script: ./scripts/your-script.sh
Hook was not triggered on the expected event:
1. Verify that the event name is correct (case-sensitive): PostToolUse, not postToolUse.
2. Check whether the matcher pattern matches the target tool: "matcher": "Write|Edit" is used for file operations.
3. Verify that the hook type is valid: command, http, prompt, or agent.

MCP Server Troubleshooting

Server not started:
1. Check whether the command exists and is executable.
2. Verify that all paths use the ${CODEBUDDY_PLUGIN_ROOT} variable.
3. Check the MCP server logs: codebuddy --debug shows initialization errors.
4. Manually test the server outside of CodeBuddy.
Server tool not displayed:
1. Ensure that the server is correctly configured in .mcp.json or plugin.json.
2. Verify that the server correctly implements the MCP protocol.
3. Check for connection timeouts in the debug output.

Directory Structure Errors

Symptom: The plugin loads, but components (commands, agents, hooks) are missing.
Correct structure: Components must be at the plugin root, not inside .codebuddy-plugin/. Only plugin.json belongs in .codebuddy-plugin/.
my-plugin/
├── .codebuddy-plugin/
│ └── plugin.json <- Only the manifest goes here.
├── commands/ <- At the root level
├── agents/ <- At the root level
└── hooks/ <- At the root level
If the components are inside .codebuddy-plugin/, move them to the plugin root directory.
Debugging checklist:
1. Run codebuddy --debug and look for the "loading plugin" message.
2. Check whether each component directory is listed in the debug output.
3. Verify that the file permissions allow reading the plugin files.

8. Version Management Reference

Semantic Versioning

Publish plugins following semantic versioning:
{
"name": "my-plugin",
"version": "2.1.0"
}
Version format: MAJOR.MINOR.PATCH
MAJOR: Incompatible API changes
MINOR: Backward-compatible feature additions
PATCH: Backward-compatible bug fixes
Tips:
The first stable version starts from 1.0.0.
Update the version in plugin.json before distributing changes.
Record changes in the CHANGELOG.md file.
Use a prerelease version (such as 2.0.0-beta.1) for testing.
Note:
CodeBuddy uses versions to determine whether a plugin needs to be updated. If you change the plugin code but do not update the version in plugin.json, existing users will not see the changes due to the caching mechanism.
If the plugin is in the Marketplace directory, you can manage versions through marketplace.json and omit the version field from plugin.json.

Versioned Cache

CodeBuddy calculates cache keys in the following order of priority:
1. The version in plugin.json
2. The version of the marketplace plugin entry
3. The commit SHA from the Git source; git-subdir also includes the subdirectory path hash.
4. Use unknown when the version cannot be determined.
Git plugins without an explicit version use the 12-character commit SHA as the cache directory name. When tags are resolved through version constraints, the cache directory additionally includes a 12-character commit SHA suffix. Constraint validation uses the separately recorded resolvedVersion and does not rely on the manifest version, which may be outdated.
Git marketplace plugins whose old version was recorded as unknown are automatically migrated at startup. CodeBuddy resolves the commit SHA from the current marketplace checkout, materializes the source code into the corresponding SHA cache directory, and then atomically updates installed_plugins.json. The old unknown directory is only marked as orphan. It is retained for at least 14 days and will not be deleted while the .in_use marker indicates an active session. Plugins from non-Git sources without an explicit version continue to use unknown.

9. Compatibility with Claude Code

The CodeBuddy plugin system is designed to be compatible with the Claude Code plugin specification, with the following differences:

Naming Differences

Concept
Claude Code
CodeBuddy
Metadata Directory
.claude-plugin/
.codebuddy-plugin/ (preferred), .workbuddy-plugin/, or .claude-plugin/ (compatible)
Environment Variable
${CLAUDE_PLUGIN_ROOT}
${CODEBUDDY_PLUGIN_ROOT} (preferred) or ${CLAUDE_PLUGIN_ROOT} (compatible)
Data Directory Variable
${CLAUDE_PLUGIN_DATA}
${CODEBUDDY_PLUGIN_DATA} (preferred) or ${CLAUDE_PLUGIN_DATA} (compatible)

Migration Guide

Migrating from Claude Code to CodeBuddy:
1. You can optionally rename .claude-plugin/ to .codebuddy-plugin/.
2. You can optionally replace ${CLAUDE_PLUGIN_ROOT} in the script with ${CODEBUDDY_PLUGIN_ROOT}.
3. You can optionally replace ${CLAUDE_PLUGIN_DATA} with ${CODEBUDDY_PLUGIN_DATA}.
Note:
Keeping the original naming is also fully compatible, and CodeBuddy will automatically recognize it.

Relevant Resources

Plugins - Tutorials and practical guides
Plugin Marketplace - Create and manage marketplaces
Skills - Skill development details
Subagents - Agent configuration and capabilities
Hooks - Event handling and automation
MCP - External tool integration
Settings - Plugin configuration options

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback