Skip to main content
ChatCLI supports a plugin system to extend its functionality. A plugin is an executable that follows a specific contract, allowing ChatCLI to discover, execute, and interact with it securely. This lets you create custom commands (such as @kind, @deploy) that can orchestrate tools, interact with APIs, or perform any logic you can program.

For Users: Managing Plugins

List installed plugins

Shows all available plugin commands, including [builtin] plugins (such as @coder) and [remote] plugins (from connected servers).

Install a plugin

Install directly from a Git repository:
ChatCLI will clone, compile (if it’s Go), and install the executable in ~/.chatcli/plugins/.
Security: Installing a plugin involves downloading and executing third-party code. Only install plugins from sources you trust.

View plugin details

Uninstall a plugin

Reload plugins

ChatCLI automatically monitors ~/.chatcli/plugins/ and reloads when it detects changes (creation, removal, modification). A 500ms debounce prevents multiple reloads. To force a manual reload:
Develop plugins iteratively: edit the code, recompile, send it to the plugins directory — ChatCLI will detect the change automatically.

For Developers: Creating a Plugin

The plugin contract

  1. Executable — The plugin must be an executable file (any language)
  2. Location — Placed in ~/.chatcli/plugins/
  3. Command name — The file name becomes the command. E.g., file kind = command @kind
  4. Metadata (--metadata) — Required. The executable must respond to this flag with JSON:
  1. Schema (--schema) — Optional. Describes the accepted parameters:
  1. Communication (stdout vs stderr):
    • stdout — Only the final result (returned to ChatCLI/AI)
    • stderr — Progress logs, status, and warnings (displayed in real time to the user)

Example: “Hello World” Plugin in Go

Compilation and installation


Capability Interfaces (opt-in)

Plugins can expose capabilities through optional Go interfaces. Legacy plugins that don’t implement them keep working unchanged — every interface is fail-closed (conservative default). When implemented, the plugin participates in orchestrator optimizations: Example — a plugin that wants auto-allow + parallelization + custom label:
The four atomic plugins (@read, @search, @tree, @todo) — see Atomic Tools — use every relevant capability as a reference implementation.

Signature Verification

Starting with this version, plugins require Ed25519 digital signatures by default. This ensures that only plugins from trusted sources are loaded and executed.

How It Works

Each plugin must have a corresponding .sig file in the same directory:
ChatCLI verifies the signature against registered public keys before loading the plugin. If verification fails, the plugin is rejected.

Managing Trusted Keys

Ed25519 public keys are stored in the ~/.chatcli/trusted-keys/ directory:
1

Generate a key pair

2

Sign a plugin

3

Distribute the public key

Share the .pub file with users who should trust your plugins. They should place it in ~/.chatcli/trusted-keys/.

File Permissions

The plugins directory uses 0o700 permissions (owner-only read, write, and execute). ChatCLI checks permissions on startup and warns if they are more permissive.

Development Mode

For local development, you can disable signature verification:
Never enable CHATCLI_ALLOW_UNSIGNED_PLUGINS in production. Unsigned plugins can execute arbitrary code with the ChatCLI process permissions.

Remote Plugins

When connecting to a server via chatcli connect, server plugins are discovered automatically:
  • They appear in /plugin list with the [remote] tag
  • They are executed on the server (not downloaded locally by default)
  • Local and remote plugins coexist without conflict