mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-04-25 00:51:20 +00:00
Plugins now require explicit consent to load. Discovery still finds every plugin — user-installed, bundled, and pip — so they all show up in `hermes plugins` and `/plugins`, but the loader only instantiates plugins whose name appears in `plugins.enabled` in config.yaml. This removes the previous ambient-execution risk where a newly-installed or bundled plugin could register hooks, tools, and commands on first run without the user opting in. The three-state model is now explicit: enabled — in plugins.enabled, loads on next session disabled — in plugins.disabled, never loads (wins over enabled) not enabled — discovered but never opted in (default for new installs) `hermes plugins install <repo>` prompts "Enable 'name' now? [y/N]" (defaults to no). New `--enable` / `--no-enable` flags skip the prompt for scripted installs. `hermes plugins enable/disable` manage both lists so a disabled plugin stays explicitly off even if something later adds it to enabled. Config migration (schema v20 → v21): existing user plugins already installed under ~/.hermes/plugins/ (minus anything in plugins.disabled) are auto-grandfathered into plugins.enabled so upgrades don't silently break working setups. Bundled plugins are NOT grandfathered — even existing users have to opt in explicitly. Also: HERMES_DISABLE_BUNDLED_PLUGINS env var removed (redundant with opt-in default), cmd_list now shows bundled + user plugins together with their three-state status, interactive UI tags bundled entries [bundled], docs updated across plugins.md and built-in-plugins.md. Validation: 442 plugin/config tests pass. E2E: fresh install discovers disk-cleanup but does not load it; `hermes plugins enable disk-cleanup` activates hooks; migration grandfathers existing user plugins correctly while leaving bundled plugins off.
240 lines
10 KiB
Markdown
240 lines
10 KiB
Markdown
---
|
|
sidebar_position: 11
|
|
sidebar_label: "Plugins"
|
|
title: "Plugins"
|
|
description: "Extend Hermes with custom tools, hooks, and integrations via the plugin system"
|
|
---
|
|
|
|
# Plugins
|
|
|
|
Hermes has a plugin system for adding custom tools, hooks, and integrations without modifying core code.
|
|
|
|
**→ [Build a Hermes Plugin](/docs/guides/build-a-hermes-plugin)** — step-by-step guide with a complete working example.
|
|
|
|
## Quick overview
|
|
|
|
Drop a directory into `~/.hermes/plugins/` with a `plugin.yaml` and Python code:
|
|
|
|
```
|
|
~/.hermes/plugins/my-plugin/
|
|
├── plugin.yaml # manifest
|
|
├── __init__.py # register() — wires schemas to handlers
|
|
├── schemas.py # tool schemas (what the LLM sees)
|
|
└── tools.py # tool handlers (what runs when called)
|
|
```
|
|
|
|
Start Hermes — your tools appear alongside built-in tools. The model can call them immediately.
|
|
|
|
### Minimal working example
|
|
|
|
Here is a complete plugin that adds a `hello_world` tool and logs every tool call via a hook.
|
|
|
|
**`~/.hermes/plugins/hello-world/plugin.yaml`**
|
|
|
|
```yaml
|
|
name: hello-world
|
|
version: "1.0"
|
|
description: A minimal example plugin
|
|
```
|
|
|
|
**`~/.hermes/plugins/hello-world/__init__.py`**
|
|
|
|
```python
|
|
"""Minimal Hermes plugin — registers a tool and a hook."""
|
|
|
|
|
|
def register(ctx):
|
|
# --- Tool: hello_world ---
|
|
schema = {
|
|
"name": "hello_world",
|
|
"description": "Returns a friendly greeting for the given name.",
|
|
"parameters": {
|
|
"type": "object",
|
|
"properties": {
|
|
"name": {
|
|
"type": "string",
|
|
"description": "Name to greet",
|
|
}
|
|
},
|
|
"required": ["name"],
|
|
},
|
|
}
|
|
|
|
def handle_hello(params):
|
|
name = params.get("name", "World")
|
|
return f"Hello, {name}! 👋 (from the hello-world plugin)"
|
|
|
|
ctx.register_tool("hello_world", schema, handle_hello)
|
|
|
|
# --- Hook: log every tool call ---
|
|
def on_tool_call(tool_name, params, result):
|
|
print(f"[hello-world] tool called: {tool_name}")
|
|
|
|
ctx.register_hook("post_tool_call", on_tool_call)
|
|
```
|
|
|
|
Drop both files into `~/.hermes/plugins/hello-world/`, restart Hermes, and the model can immediately call `hello_world`. The hook prints a log line after every tool invocation.
|
|
|
|
Project-local plugins under `./.hermes/plugins/` are disabled by default. Enable them only for trusted repositories by setting `HERMES_ENABLE_PROJECT_PLUGINS=true` before starting Hermes.
|
|
|
|
## What plugins can do
|
|
|
|
| Capability | How |
|
|
|-----------|-----|
|
|
| Add tools | `ctx.register_tool(name, schema, handler)` |
|
|
| Add hooks | `ctx.register_hook("post_tool_call", callback)` |
|
|
| Add slash commands | `ctx.register_command(name, handler, description)` — adds `/name` in CLI and gateway sessions |
|
|
| Add CLI commands | `ctx.register_cli_command(name, help, setup_fn, handler_fn)` — adds `hermes <plugin> <subcommand>` |
|
|
| Inject messages | `ctx.inject_message(content, role="user")` — see [Injecting Messages](#injecting-messages) |
|
|
| Ship data files | `Path(__file__).parent / "data" / "file.yaml"` |
|
|
| Bundle skills | `ctx.register_skill(name, path)` — namespaced as `plugin:skill`, loaded via `skill_view("plugin:skill")` |
|
|
| Gate on env vars | `requires_env: [API_KEY]` in plugin.yaml — prompted during `hermes plugins install` |
|
|
| Distribute via pip | `[project.entry-points."hermes_agent.plugins"]` |
|
|
|
|
## Plugin discovery
|
|
|
|
| Source | Path | Use case |
|
|
|--------|------|----------|
|
|
| Bundled | `<repo>/plugins/` | Ships with Hermes — see [Built-in Plugins](/docs/user-guide/features/built-in-plugins) |
|
|
| User | `~/.hermes/plugins/` | Personal plugins |
|
|
| Project | `.hermes/plugins/` | Project-specific plugins (requires `HERMES_ENABLE_PROJECT_PLUGINS=true`) |
|
|
| pip | `hermes_agent.plugins` entry_points | Distributed packages |
|
|
|
|
Later sources override earlier ones on name collision, so a user plugin with the same name as a bundled plugin replaces it.
|
|
|
|
## Plugins are opt-in
|
|
|
|
**Every plugin — user-installed, bundled, or pip — is disabled by default.** Discovery finds them (so they show up in `hermes plugins` and `/plugins`), but nothing loads until you add the plugin's name to `plugins.enabled` in `~/.hermes/config.yaml`. This stops anything with hooks or tools from running without your explicit consent.
|
|
|
|
```yaml
|
|
plugins:
|
|
enabled:
|
|
- my-tool-plugin
|
|
- disk-cleanup
|
|
disabled: # optional deny-list — always wins if a name appears in both
|
|
- noisy-plugin
|
|
```
|
|
|
|
Three ways to flip state:
|
|
|
|
```bash
|
|
hermes plugins # interactive toggle (space to check/uncheck)
|
|
hermes plugins enable <name> # add to allow-list
|
|
hermes plugins disable <name> # remove from allow-list + add to disabled
|
|
```
|
|
|
|
After `hermes plugins install owner/repo`, you're asked `Enable 'name' now? [y/N]` — defaults to no. Skip the prompt for scripted installs with `--enable` or `--no-enable`.
|
|
|
|
### Migration for existing users
|
|
|
|
When you upgrade to a version of Hermes that has opt-in plugins (config schema v21+), any user plugins already installed under `~/.hermes/plugins/` that weren't already in `plugins.disabled` are **automatically grandfathered** into `plugins.enabled`. Your existing setup keeps working. Bundled plugins are NOT grandfathered — even existing users have to opt in explicitly.
|
|
|
|
## Available hooks
|
|
|
|
Plugins can register callbacks for these lifecycle events. See the **[Event Hooks page](/docs/user-guide/features/hooks#plugin-hooks)** for full details, callback signatures, and examples.
|
|
|
|
| Hook | Fires when |
|
|
|------|-----------|
|
|
| [`pre_tool_call`](/docs/user-guide/features/hooks#pre_tool_call) | Before any tool executes |
|
|
| [`post_tool_call`](/docs/user-guide/features/hooks#post_tool_call) | After any tool returns |
|
|
| [`pre_llm_call`](/docs/user-guide/features/hooks#pre_llm_call) | Once per turn, before the LLM loop — can return `{"context": "..."}` to [inject context into the user message](/docs/user-guide/features/hooks#pre_llm_call) |
|
|
| [`post_llm_call`](/docs/user-guide/features/hooks#post_llm_call) | Once per turn, after the LLM loop (successful turns only) |
|
|
| [`on_session_start`](/docs/user-guide/features/hooks#on_session_start) | New session created (first turn only) |
|
|
| [`on_session_end`](/docs/user-guide/features/hooks#on_session_end) | End of every `run_conversation` call + CLI exit handler |
|
|
|
|
## Plugin types
|
|
|
|
Hermes has three kinds of plugins:
|
|
|
|
| Type | What it does | Selection | Location |
|
|
|------|-------------|-----------|----------|
|
|
| **General plugins** | Add tools, hooks, slash commands, CLI commands | Multi-select (enable/disable) | `~/.hermes/plugins/` |
|
|
| **Memory providers** | Replace or augment built-in memory | Single-select (one active) | `plugins/memory/` |
|
|
| **Context engines** | Replace the built-in context compressor | Single-select (one active) | `plugins/context_engine/` |
|
|
|
|
Memory providers and context engines are **provider plugins** — only one of each type can be active at a time. General plugins can be enabled in any combination.
|
|
|
|
## Managing plugins
|
|
|
|
```bash
|
|
hermes plugins # unified interactive UI
|
|
hermes plugins list # table: enabled / disabled / not enabled
|
|
hermes plugins install user/repo # install from Git, then prompt Enable? [y/N]
|
|
hermes plugins install user/repo --enable # install AND enable (no prompt)
|
|
hermes plugins install user/repo --no-enable # install but leave disabled (no prompt)
|
|
hermes plugins update my-plugin # pull latest
|
|
hermes plugins remove my-plugin # uninstall
|
|
hermes plugins enable my-plugin # add to allow-list
|
|
hermes plugins disable my-plugin # remove from allow-list + add to disabled
|
|
```
|
|
|
|
### Interactive UI
|
|
|
|
Running `hermes plugins` with no arguments opens a composite interactive screen:
|
|
|
|
```
|
|
Plugins
|
|
↑↓ navigate SPACE toggle ENTER configure/confirm ESC done
|
|
|
|
General Plugins
|
|
→ [✓] my-tool-plugin — Custom search tool
|
|
[ ] webhook-notifier — Event hooks
|
|
[ ] disk-cleanup — Auto-cleanup of ephemeral files [bundled]
|
|
|
|
Provider Plugins
|
|
Memory Provider ▸ honcho
|
|
Context Engine ▸ compressor
|
|
```
|
|
|
|
- **General Plugins section** — checkboxes, toggle with SPACE. Checked = in `plugins.enabled`, unchecked = in `plugins.disabled` (explicit off).
|
|
- **Provider Plugins section** — shows current selection. Press ENTER to drill into a radio picker where you choose one active provider.
|
|
- Bundled plugins appear in the same list with a `[bundled]` tag.
|
|
|
|
Provider plugin selections are saved to `config.yaml`:
|
|
|
|
```yaml
|
|
memory:
|
|
provider: "honcho" # empty string = built-in only
|
|
|
|
context:
|
|
engine: "compressor" # default built-in compressor
|
|
```
|
|
|
|
### Enabled vs. disabled vs. neither
|
|
|
|
Plugins occupy one of three states:
|
|
|
|
| State | Meaning | In `plugins.enabled`? | In `plugins.disabled`? |
|
|
|---|---|---|---|
|
|
| `enabled` | Loaded on next session | Yes | No |
|
|
| `disabled` | Explicitly off — won't load even if also in `enabled` | (irrelevant) | Yes |
|
|
| `not enabled` | Discovered but never opted in | No | No |
|
|
|
|
The default for a newly-installed or bundled plugin is `not enabled`. `hermes plugins list` shows all three distinct states so you can tell what's been explicitly turned off vs. what's just waiting to be enabled.
|
|
|
|
In a running session, `/plugins` shows which plugins are currently loaded.
|
|
|
|
## Injecting Messages
|
|
|
|
Plugins can inject messages into the active conversation using `ctx.inject_message()`:
|
|
|
|
```python
|
|
ctx.inject_message("New data arrived from the webhook", role="user")
|
|
```
|
|
|
|
**Signature:** `ctx.inject_message(content: str, role: str = "user") -> bool`
|
|
|
|
How it works:
|
|
|
|
- If the agent is **idle** (waiting for user input), the message is queued as the next input and starts a new turn.
|
|
- If the agent is **mid-turn** (actively running), the message interrupts the current operation — the same as a user typing a new message and pressing Enter.
|
|
- For non-`"user"` roles, the content is prefixed with `[role]` (e.g. `[system] ...`).
|
|
- Returns `True` if the message was queued successfully, `False` if no CLI reference is available (e.g. in gateway mode).
|
|
|
|
This enables plugins like remote control viewers, messaging bridges, or webhook receivers to feed messages into the conversation from external sources.
|
|
|
|
:::note
|
|
`inject_message` is only available in CLI mode. In gateway mode, there is no CLI reference and the method returns `False`.
|
|
:::
|
|
|
|
See the **[full guide](/docs/guides/build-a-hermes-plugin)** for handler contracts, schema format, hook behavior, error handling, and common mistakes.
|