• Features
• Core
• Built-in Plugins

Built-in Plugins

Hermes ships a small set of plugins bundled with the repository. They live under/plugins//and load automatically alongside user-installed plugins in~/.hermes/plugins/. They use the same plugin surface as third-party plugins — hooks, tools, slash commands — just maintained in-tree.

<repo>/plugins/<name>/ ~/.hermes/plugins/

See thePluginspage for the general plugin system, andBuild a Hermes Pluginto write your own.

How discovery works​

ThePluginManagerscans four sources, in order:

PluginManager

1. Bundled—/plugins//(what this page documents)
2. User—~/.hermes/plugins//
3. Project—./.hermes/plugins//(requiresHERMES_ENABLE_PROJECT_PLUGINS=1)
4. Pip entry points—hermes_agent.plugins

<repo>/plugins/<name>/ ~/.hermes/plugins/<name>/ ./.hermes/plugins/<name>/ HERMES_ENABLE_PROJECT_PLUGINS=1 hermes_agent.plugins

On name collision, later sources win — a user plugin nameddisk-cleanupwould replace the bundled one.

disk-cleanup

plugins/memory/andplugins/context_engine/are deliberately excluded from bundled scanning. Those directories use their own discovery paths because memory providers and context engines are single-select providers configured throughhermes memory setup/context.enginein config.

plugins/memory/ plugins/context_engine/ hermes memory setup context.engine

Bundled plugins are opt-in​

Bundled plugins ship disabled. Discovery finds them (they appear inhermes plugins listand the interactivehermes pluginsUI), but none load until you explicitly enable them:

hermes plugins list hermes plugins

hermes plugins enable disk-cleanup

Or via~/.hermes/config.yaml:

~/.hermes/config.yaml

plugins:  enabled:    - disk-cleanup

This is the same mechanism user-installed plugins use. Bundled plugins are never auto-enabled — not on fresh install, not for existing users upgrading to a newer Hermes. You always opt in explicitly.

To turn a bundled plugin off again:

hermes plugins disable disk-cleanup# or: remove it from plugins.enabled in config.yaml

Currently shipped​

The repo ships these bundled plugins underplugins/. All are opt-in — enable them viahermes plugins enable .

plugins/ hermes plugins enable <name> | Plugin | Kind | Purpose | | — | — | — | | disk-cleanup | hooks + slash command | Auto-track ephemeral files and clean them on session end | | security-guidance | hooks | Pattern-match dangerous code onwrite_file/patchand append a security warning (or block) — 25 rules (Apache-2.0 fork of Anthropic’sclaude-plugins-officialpatterns) | | observability/langfuse | hooks | Trace turns / LLM calls / tools toLangfuse | | observability/nemo_relay | hooks | Relay observability events (turns / LLM calls / tools) to an NVIDIA NeMo endpoint | | teams_pipeline | standalone | Microsoft Teams meeting pipeline — Graph-backed, transcript-first meeting summaries | | spotify | backend (7 tools) | Native Spotify playback, queue, search, playlists, albums, library | | google_meet | standalone | Join Meet calls, live-caption transcription, optional realtime duplex audio | | image_gen/openai | image backend | OpenAIgpt-image-2image generation backend (alternative to FAL) | | image_gen/openai-codex | image backend | OpenAI image generation via Codex OAuth | | image_gen/xai | image backend | xAIgrok-2-imagebackend | | hermes-achievements | dashboard tab | Steam-style collectible badges generated from your real Hermes session history | | kanban/dashboard | dashboard tab | Kanban board UI for the multi-agent dispatcher — tasks, comments, fan-out, board switching. SeeKanban Multi-Agent. |

disk-cleanup security-guidance write_file patch claude-plugins-official observability/langfuse observability/nemo_relay teams_pipeline spotify google_meet image_gen/openai gpt-image-2 image_gen/openai-codex image_gen/xai grok-2-image hermes-achievements kanban/dashboard

Memory providers (plugins/memory/) and context engines (plugins/context_engine/) are listed separately onMemory Providers— they’re managed throughhermes memoryandhermes pluginsrespectively. The full per-plugin detail for the two long-running hooks-based plugins follows.

plugins/memory/* plugins/context_engine/* hermes memory hermes plugins

disk-cleanup​

Auto-tracks and removes ephemeral files created during sessions — test scripts, temp outputs, cron logs, stale chrome profiles — without requiring the agent to remember to call a tool.

How it works:

post_tool_call write_file terminal patch test_* tmp_* *.test.* HERMES_HOME /tmp/hermes-* test temp cron-output on_session_end quick

Deletion rules:

test temp cron-output research chrome-profile

Slash command—/disk-cleanupavailable in both CLI and gateway sessions:

/disk-cleanup

/disk-cleanup status                     # breakdown + top-10 largest/disk-cleanup dry-run                    # preview without deleting/disk-cleanup quick                      # run safe cleanup now/disk-cleanup deep                       # quick + list items needing confirmation/disk-cleanup track <path> <category>    # manual tracking/disk-cleanup forget <path>              # stop tracking (does not delete)

State— everything lives at$HERMES_HOME/disk-cleanup/:

$HERMES_HOME/disk-cleanup/ | File | Contents | | — | — | | tracked.json | Tracked paths with category, size, and timestamp | | tracked.json.bak | Atomic-write backup of the above | | cleanup.log | Append-only audit trail of every track / skip / reject / delete |

tracked.json tracked.json.bak cleanup.log

Safety— cleanup only ever touches paths underHERMES_HOMEor/tmp/hermes-*. Windows mounts (/mnt/c/…) are rejected. Well-known top-level state dirs (logs/,memories/,sessions/,cron/,cache/,skills/,plugins/,disk-cleanup/itself) are never removed even when empty — a fresh install does not get gutted on first session end.

HERMES_HOME /tmp/hermes-* /mnt/c/... logs/ memories/ sessions/ cron/ cache/ skills/ plugins/ disk-cleanup/

Enabling:hermes plugins enable disk-cleanup(or check the box inhermes plugins).

hermes plugins enable disk-cleanup hermes plugins

Disabling again:hermes plugins disable disk-cleanup.

hermes plugins disable disk-cleanup

security-guidance​

Fast pattern-matched security warnings on file writes. When the agent’swrite_file/patch/skill_managecalls carry content matching a known-dangerous code pattern —pickle.load,yaml.loadwithoutSafeLoader,eval(,os.system,subprocess(…, shell=True), JSchild_process.exec, ReactdangerouslySetInnerHTML, raw.innerHTML =/.outerHTML =/document.write, Nodecrypto.createCipher, AES ECB mode, TLS verification disabled, XXE-pronexml.etree/minidomparsers,

write_file patch skill_manage pickle.load yaml.load SafeLoader eval( os.system subprocess(..., shell=True) child_process.exec dangerouslySetInnerHTML .innerHTML = .outerHTML = document.write crypto.createCipher xml.etree minidom <script src="//..." > torch.load weights_only=True $ ⚠️ Security guidance

The file is still written. The model reads the warning in the next turn’s tool message and can either fix the code or document why the construct is safe in this context. Pattern matching has a non-trivial false-positive rate, which is why warn (not block) is the default.

Coverage:25 rules total, covering unsafe deserialization, command injection, XSS sinks, crypto footguns, XXE, supply-chain (SRI), and CI/CD workflow injection. The pattern data is a verbatim Apache-2.0 fork ofAnthropic’sclaude-plugins-official— see the plugin’sLICENSEandNOTICEfiles for attribution.

claude-plugins-official LICENSE NOTICE

Modes:

SECURITY_GUIDANCE_BLOCK=1 SECURITY_GUIDANCE_DISABLE=1

Enabling:hermes plugins enable security-guidance(or check the box inhermes plugins).

hermes plugins enable security-guidance hermes plugins

Disabling again:hermes plugins disable security-guidance.

hermes plugins disable security-guidance

What it does not do (yet):the upstream Anthropic plugin has two more layers — an LLM diff review on each agent turn that touched files, and an agentic commit-time review that traces data flow across files. Neither is ported. The agent can already run those reviews on demand viadelegate_task.

delegate_task

observability/langfuse​

Traces Hermes turns, LLM calls, and tool invocations toLangfuse— an open-source LLM observability platform. One span per turn, one generation per API call, one tool observation per tool call. Usage totals, per-type token counts, and cost estimates come out of Hermes’ canonicalagent.usage_pricingnumbers, so the Langfuse dashboard sees the same breakdown (input / output /cache_read_input_tokens/cache_creation_input_tokens/reasoning_tokens) that appears inhermes logs.

agent.usage_pricing cache_read_input_tokens cache_creation_input_tokens reasoning_tokens hermes logs

The plugin is fail-open: no SDK installed, no credentials, or a transient Langfuse error — all turn into a silent no-op in the hook. The agent loop is never impacted.

Setup (interactive — recommended):

hermes tools          # → Langfuse Observability → Cloud or Self-Hosted

The wizard collects your keys,pip installs thelangfuseSDK, and addsobservability/langfusetoplugins.enabledfor you. Restart Hermes and the next turn ships a trace.

pip install langfuse observability/langfuse plugins.enabled

Setup (manual):

pip install langfusehermes plugins enable observability/langfuse

Then put the credentials in~/.hermes/.env:

~/.hermes/.env

HERMES_LANGFUSE_PUBLIC_KEY=pk-lf-...HERMES_LANGFUSE_SECRET_KEY=sk-lf-...HERMES_LANGFUSE_BASE_URL=https://cloud.langfuse.com   # or your self-hosted URL

How it works:

pre_api_request pre_llm_call generation post_api_request post_llm_call usage_details cost_details finish_reason pre_tool_call tool args post_tool_call result read_file HERMES_LANGFUSE_MAX_CHARS

Session grouping keys off the Hermes session ID (or task ID for sub-agents) vialangfuse.propagate_attributes, so everything in a singlehermes chatsession lives under one Langfuse session.

langfuse.propagate_attributes hermes chat

Verify:

hermes plugins list                 # observability/langfuse should show "enabled"hermes chat -q "hello"              # check the Langfuse UI for a "Hermes turn" trace

Optional tuning(in.env):

.env | Variable | Default | Purpose | | — | — | — | | HERMES_LANGFUSE_ENV | — | Environment tag on traces (production,staging, …) | | HERMES_LANGFUSE_RELEASE | — | Release/version tag | | HERMES_LANGFUSE_SAMPLE_RATE | 1.0 | Sampling rate passed to the SDK (0.0–1.0) | | HERMES_LANGFUSE_MAX_CHARS | 12000 | Per-field truncation for message content / tool args / tool results | | HERMES_LANGFUSE_DEBUG | false | Verbose plugin logging toagent.log |

HERMES_LANGFUSE_ENV production staging HERMES_LANGFUSE_RELEASE HERMES_LANGFUSE_SAMPLE_RATE 1.0 HERMES_LANGFUSE_MAX_CHARS 12000 HERMES_LANGFUSE_DEBUG false agent.log

Hermes-prefixed and standard SDK env vars (LANGFUSE_PUBLIC_KEY,LANGFUSE_SECRET_KEY,LANGFUSE_BASE_URL) are both accepted — Hermes-prefixed wins when both are set.

LANGFUSE_PUBLIC_KEY LANGFUSE_SECRET_KEY LANGFUSE_BASE_URL

Performance:the Langfuse client is cached after the first hook call. If credentials or SDK are missing, that decision is also cached — subsequent hooks fast-return without re-checking env vars or reloading config.

Disabling:hermes plugins disable observability/langfuse. The plugin module is still discovered, but no module code runs until you re-enable.

hermes plugins disable observability/langfuse

google_meet​

Lets the agentjoin, transcribe, and participate in Google Meet calls— take notes on a meeting, summarize the back-and-forth after, follow up on specific points, and (optionally) speak replies back into the call via TTS.

What it adds:

• A headless virtual participant that joins a Meet URL using browser automation
• Live transcription of the meeting audio via the configured STT provider
• Ameet_summarize/meet_speak/meet_followuptoolset the agent invokes to act on what it heard
• Post-meeting artifacts (transcript, speaker-attributed notes, action items) saved under~/.hermes/cache/google_meet//

meet_summarize meet_speak meet_followup ~/.hermes/cache/google_meet/<meeting_id>/

Setup:

hermes plugins enable google_meet# Prompts you to sign in via the plugin's OAuth flow on first use —# needs a Google account with Meet access. Host approval may be required# if the meeting enforces "only invited participants can join".

Usage from chat:

“Join meet.google.com/abc-defg-hij and take notes. After the call, send me a summary with action items.”

“Join meet.google.com/abc-defg-hij and take notes. After the call, send me a summary with action items.”

The agent kicks off the meeting join, streams the transcription back into its context as the call proceeds, and produces a structured summary when the meeting ends (or when you tell it to stop).

When to use it:recurring standups where you want a bot to transcribe + summarize for async attendees; deposition-style interviews where you want structured notes; any case where you’d otherwise need Fireflies / Otter / Grain. When you’d rather not have an AI listening in — don’t enable it.

Disabling:hermes plugins disable google_meet. Any cached transcripts and recordings stay in~/.hermes/cache/google_meet/until you remove them.

hermes plugins disable google_meet ~/.hermes/cache/google_meet/

hermes-achievements​

Adds aSteam-style achievements tab to the dashboard— 60+ collectible, tiered badges generated from your real Hermes session history. Tool-chain feats, debugging patterns, vibe-coding streaks, skill/memory usage, model/provider variety, lifestyle quirks (weekend and night sessions). Originally authored by@PCinkuszas an external plugin; brought in-tree so it stays in lockstep with Hermes feature changes.

How it works:

• Scans your entire~/.hermes/state.dbsession history on the dashboard backend
• Per-session stats are cached by(started_at, last_active)fingerprint, so only new or changed sessions re-analyze on subsequent scans
• First-ever scan runs in a background thread — the dashboard never blocks waiting for it, even on databases with thousands of sessions
• Unlock state is persisted to$HERMES_HOME/plugins/hermes-achievements/state.json

~/.hermes/state.db (started_at, last_active) $HERMES_HOME/plugins/hermes-achievements/state.json

Tier progression:Copper → Silver → Gold → Diamond → Olympian. Each card exposes a “What counts” section listing the exact metric being tracked.

Achievement states:

API— routes mount under/api/plugins/hermes-achievements/:

/api/plugins/hermes-achievements/ | Endpoint | Purpose | | — | — | | GET /achievements | Full catalog with per-badge unlock state (returns a pending placeholder while the first cold scan is running) | | GET /scan-status | State of the background scanner:idle/running/failed, last duration, run count | | GET /recent-unlocks | Twenty most recently unlocked badges, newest first | | GET /sessions/{id}/badges | Badges earned primarily in one specific session | | POST /rescan | Manual synchronous rescan (blocks; use when the user clicks the rescan button) | | POST /reset-state | Clear unlock history and cached snapshot |

GET /achievements GET /scan-status idle running failed GET /recent-unlocks GET /sessions/{id}/badges POST /rescan POST /reset-state

State files— live under$HERMES_HOME/plugins/hermes-achievements/:

$HERMES_HOME/plugins/hermes-achievements/ | File | Contents | | — | — | | state.json | Unlock history: which badges you’ve earned and when. Stable across Hermes updates. | | scan_snapshot.json | Last completed scan payload (served immediately on dashboard load) | | scan_checkpoint.json | Per-session stats cache keyed by fingerprint (makes warm rescans fast) |

state.json scan_snapshot.json scan_checkpoint.json

Performance notes:

• Cold scan on ~8,000 sessions takes a few minutes. It runs in a background thread on first dashboard request; the UI sees a pending placeholder and polls/scan-status.
• Incremental results during a cold scan— the scanner publishes a partial snapshot every ~250 sessions so each dashboard refresh shows more badges unlocked as the scan progresses. No minute-long stare at zeros.
• Warm rescan reuses per-session stats for every session whosestarted_at+last_activefingerprint matches the checkpoint — completes in seconds even on large histories.
• The in-memory snapshot TTL is 120s; stale requests serve the old snapshot immediately and kick a background refresh. You never wait on a spinner just because TTL expired.

/scan-status started_at last_active

Enabling:Nothing to enable —hermes-achievementsis a dashboard-only plugin (no lifecycle hooks, no model-visible tools). It auto-registers as a tab inhermes dashboardon first launch. Theplugins.enabledconfig only gates lifecycle/tool plugins; dashboard plugins are discovered purely via theirdashboard/manifest.json.

hermes-achievements hermes dashboard plugins.enabled dashboard/manifest.json

Opting out:Delete or renameplugins/hermes-achievements/dashboard/manifest.json, or override it with a user plugin of the same name in~/.hermes/plugins/hermes-achievements/that ships no dashboard. The plugin’s state files under$HERMES_HOME/plugins/hermes-achievements/survive — reinstalling preserves your unlock history.

plugins/hermes-achievements/dashboard/manifest.json ~/.hermes/plugins/hermes-achievements/ $HERMES_HOME/plugins/hermes-achievements/

Adding a bundled plugin​

Bundled plugins are written exactly like any other Hermes plugin — seeBuild a Hermes Plugin. The only differences are:

• Directory lives at/plugins//instead of~/.hermes/plugins//
• Manifest source is reported asbundledinhermes plugins list
• User plugins with the same name override the bundled version

<repo>/plugins/<name>/ ~/.hermes/plugins/<name>/ bundled hermes plugins list

A plugin is a good candidate for bundling when:

• It has no optional dependencies (or they’re alreadypip install .[all]deps)
• The behaviour benefits most users and is opt-out rather than opt-in
• The logic ties into lifecycle hooks that the agent would otherwise have to remember to invoke
• It complements a core capability without expanding the model-visible tool surface

pip install .[all]

Counter-examples — things that should stay as user-installable plugins, not bundled: third-party integrations with API keys, niche workflows, large dependency trees, anything that would meaningfully change agent behaviour by default.