Hermes Agent Built-in Plugins: The Bundled Plugin Set

hermes plugins enable disk-cleanup

plugins:
  enabled:
    - disk-cleanup

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

Currently shipped​

The repository includes several bundled plugins located under plugins/. All are opt-in — activate them using hermes plugins enable .

Plugin	Kind	Purpose
disk-cleanup	hooks + slash command	Automatically monitor temporary files and remove them when a session ends
security-guidance	hooks	Scan for dangerous code patterns on write_file/patch calls and attach a security warning (or block the operation) — 25 rules (Apache-2.0 fork of Anthropic's claude-plugins-official patterns)
observability/langfuse	hooks	Send turn / LLM call / tool traces to Langfuse
observability/nemo_relay	hooks	Forward 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	OpenAI gpt-image-2 image generation backend (alternative to FAL)
image_gen/openai-codex	image backend	OpenAI image generation via Codex OAuth
image_gen/xai	image backend	xAI grok-2-image backend
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. See Kanban Multi-Agent.

Memory providers (plugins/memory/*) and context engines (plugins/context_engine/*) are documented separately on Memory Providers — they are managed through hermes memory and hermes plugins respectively. The full per-plugin detail for the two long-running hooks-based plugins follows.

disk-cleanup​

Automatically tracks and removes temporary 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:

Hook	Behaviour
post_tool_call	When write_file / terminal / patch creates a file matching test_*, tmp_*, or *.test.* inside HERMES_HOME or /tmp/hermes-*, track it silently as test / temp / cron-output.
on_session_end	If any test files were auto-tracked during the turn, run the safe quick cleanup and log a one-line summary. Stays silent otherwise.

Deletion rules:

Category	Threshold	Confirmation
test	every session end	Never
temp	>7 days since tracked	Never
cron-output	>14 days since tracked	Never
empty dirs under HERMES_HOME	always	Never
research	>30 days, beyond 10 newest	Always (deep only)
chrome-profile	>14 days since tracked	Always (deep only)
files >500 MB	never auto	Always (deep only)

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

/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/:

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

Safety — cleanup only ever touches paths under HERMES_HOME or /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.

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

Disabling again: hermes plugins disable disk-cleanup.

security-guidance​

Fast pattern-matched security warnings on file writes. When the agent's write_file / patch / skill_manage calls carry content matching a known-dangerous code pattern — pickle.load, yaml.load without SafeLoader, eval(, os.system, subprocess(..., shell=True), JS child_process.exec, React dangerouslySetInnerHTML, raw .innerHTML = / .outerHTML = / document.write, Node crypto.createCipher, AES ECB mode, TLS verification disabled, XXE-prone xml.etree / minidom parsers, `` without SRI, torch.load without weights_only=True, GitHub Actions ${{ github.event.* }} injection — the plugin appends a ⚠️ Security guidance block to the tool's result.

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 of Anthropic's claude-plugins-official — see the plugin's LICENSE and NOTICE files for attribution.

Modes:

Env var	Effect
(unset)	warn mode (default) — file is written, warning appended to result
SECURITY_GUIDANCE_BLOCK=1	block mode — write refused, warning returned as the block reason
SECURITY_GUIDANCE_DISABLE=1	kill switch — plugin loads but does nothing

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

Disabling again: 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 via delegate_task.

observability/langfuse​

Hermes traces every turn, LLM call, and tool invocation to Langfuse, an open-source observability platform built for LLM applications. Each turn becomes a root span, each API call becomes a generation child observation, and each tool invocation becomes a tool observation. The usage totals, per-type token counts, and cost estimates are derived directly from Hermes' canonical agent.usage_pricing numbers, so the Langfuse dashboard displays the same breakdown (input / output / cache_read_input_tokens / cache_creation_input_tokens / reasoning_tokens) that you see in hermes logs.

The plugin operates in a fail-open mode: if the SDK is not installed, credentials are missing, or Langfuse experiences a transient error, the hook silently becomes a no-op. The agent loop remains completely unaffected.

Setup (interactive — recommended):

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

The wizard collects your API keys, runs pip install for the langfuse SDK, and automatically adds observability/langfuse to the plugins.enabled list. Restart Hermes, and the next turn will ship a trace.

Setup (manual):

pip install langfuse
hermes plugins enable observability/langfuse

Then place your credentials in ~/.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:

Hook	Behaviour
pre_api_request / pre_llm_call	Opens (or reuses) a per-turn root span named "Hermes turn". Starts a generation child observation for this API call, serializing recent messages as input.
post_api_request / post_llm_call	Closes the generation, attaching usage_details, cost_details, finish_reason, assistant output, and tool calls. If no tool calls exist and content is non-empty, the turn is closed.
pre_tool_call	Starts a tool child observation with sanitized args.
post_tool_call	Closes the tool observation with sanitized result. For read_file payloads, the content is summarized (head + tail + omitted-line count) so that large file reads stay within HERMES_LANGFUSE_MAX_CHARS.

Session grouping is driven by the Hermes session ID (or task ID for sub-agents) via langfuse.propagate_attributes, so everything within a single hermes chat session lives under one Langfuse session.

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):

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 to agent.log

Both Hermes-prefixed variables and standard SDK environment variables (LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY, LANGFUSE_BASE_URL) are accepted. When both are set, the Hermes-prefixed versions take precedence.

Performance: The Langfuse client is cached after the first hook call. If credentials or the SDK are missing, that decision is also cached, so subsequent hooks return quickly without re-checking environment variables or reloading configuration.

Disabling: Run hermes plugins disable observability/langfuse. The plugin module remains discoverable, but no module code executes until you re-enable it.

google_meet​

This plugin enables the agent to join, transcribe, and participate in Google Meet calls. The agent can take notes during a meeting, summarize the conversation afterward, follow up on specific points, and optionally speak replies back into the call using TTS.

What it adds:

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

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."

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

When to use it: Recurring standups where you want a bot to transcribe and summarize for async attendees; deposition-style interviews where structured notes are valuable; any scenario where you would otherwise rely on Fireflies, Otter, or Grain. If you prefer not to have an AI listening in, simply leave this plugin disabled.

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

hermes-achievements​

This plugin adds a Steam-style achievements tab to the dashboard, featuring over 60 collectible, tiered badges generated from your real Hermes session history. Badges cover tool-chain feats, debugging patterns, vibe-coding streaks, skill and memory usage, model and provider variety, and lifestyle quirks (such as weekend and night sessions). Originally authored by @PCinkusz as an external plugin, it has been brought in-tree so it stays in lockstep with Hermes feature changes.

How it works:

• Scans your entire ~/.hermes/state.db session history on the dashboard backend
• Per-session stats are cached by a (started_at, last_active) fingerprint, so only new or changed sessions are re-analyzed on subsequent scans
• The 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

Tier progression: Copper → Silver → Gold → Diamond → Olympian. Each card includes a "What counts" section that lists the exact metric being tracked.

Achievement states:

State	Meaning
Unlocked	At least one tier achieved
Discovered	Known achievement, progress visible, not yet earned
Secret	Hidden until Hermes detects the first related signal in your history

API — routes mount under /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

State files — live under $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)

Performance notes:

• A cold scan on approximately 8,000 sessions takes a few minutes. It runs in a background thread on the first dashboard request; the UI shows 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 reveals more unlocked badges as the scan progresses. No minute-long wait with zeros.
• A warm rescan reuses per-session stats for every session whose started_at + last_active fingerprint matches the checkpoint, completing in seconds even on large histories.
• The in-memory snapshot TTL is 120 seconds; stale requests serve the old snapshot immediately and trigger a background refresh. You never wait on a spinner just because the TTL expired.

Enabling: No action is needed — hermes-achievements is a dashboard-only plugin (no lifecycle hooks, no model-visible tools). It auto-registers as a tab in hermes dashboard on first launch. The plugins.enabled configuration only gates lifecycle and tool plugins; dashboard plugins are discovered purely through their dashboard/manifest.json.

Opting out: Delete or rename plugins/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/ persist — reinstalling preserves your unlock history.

Adding a bundled plugin

Bundled plugins are developed identically to any standard Hermes plugin — refer to Build a Hermes Plugin for the full guide. The key distinctions are:

• The plugin directory is located at /plugins// rather than ~/.hermes/plugins//
• The manifest source field displays as bundled when running hermes plugins list
• User-installed plugins sharing the same name will take precedence over the bundled version

A plugin is well-suited for bundling when:

• It has no optional dependencies (or those dependencies are already included via pip install .[all])
• The functionality benefits the majority of users and is designed as opt-out rather than opt-in
• The logic integrates with lifecycle hooks that users would otherwise need to remember to invoke manually
• It enhances a core capability without increasing the model-visible tool surface area

Situations where a plugin should remain user-installable rather than bundled include: third-party integrations requiring API keys, specialized workflows, dependencies with large installation trees, and any plugin that would materially alter agent behaviour by default.