Publish hermes-skills-autonomous-ai-agents via gitea-publish skill
This commit is contained in:
figmar
@@ -0,0 +1,101 @@
|
||||
# Durable & Background Systems
|
||||
|
||||
Four systems run alongside the main conversation loop. Quick reference
|
||||
here; full developer notes live in `AGENTS.md`, user-facing docs under
|
||||
`website/docs/user-guide/features/`.
|
||||
|
||||
### Delegation (`delegate_task`)
|
||||
|
||||
Spawn a subagent with an isolated context + terminal session.
|
||||
|
||||
- **Single:** `delegate_task(goal, context)`.
|
||||
- **Batch:** `delegate_task(tasks=[{goal, ...}, ...])` runs children in
|
||||
parallel, capped by `delegation.max_concurrent_children` (default 3).
|
||||
- **Background:** `delegate_task(background=true)` returns a handle
|
||||
immediately and keeps the parent loop going; the child's result
|
||||
re-enters the conversation as a new turn when it finishes.
|
||||
- **Roles:** `leaf` (default; cannot re-delegate) vs `orchestrator`
|
||||
(can spawn its own workers, bounded by `delegation.max_spawn_depth`).
|
||||
- **Not durable.** A backgrounded child is still process-local — if the
|
||||
parent process exits, the child is lost. For work that must outlive
|
||||
the process, use `cronjob` or
|
||||
`terminal(background=True, notify_on_complete=True)`.
|
||||
|
||||
Config: `delegation.*` in `config.yaml`.
|
||||
|
||||
### Cron (scheduled jobs)
|
||||
|
||||
Durable scheduler — `cron/jobs.py` + `cron/scheduler.py`. Drive it via
|
||||
the `cronjob` tool, the `hermes cron` CLI (`list`, `add`, `edit`,
|
||||
`pause`, `resume`, `run`, `remove`), or the `/cron` slash command.
|
||||
|
||||
- **Schedules:** duration (`"30m"`, `"2h"`), "every" phrase
|
||||
(`"every monday 9am"`), 5-field cron (`"0 9 * * *"`), or ISO timestamp.
|
||||
- **Per-job knobs:** `skills`, `model`/`provider` override, `script`
|
||||
(pre-run data collection; `no_agent=True` makes the script the whole
|
||||
job), `context_from` (chain job A's output into job B), `workdir`
|
||||
(run in a specific dir with its `AGENTS.md` / `CLAUDE.md` loaded),
|
||||
multi-platform delivery.
|
||||
- **Invariants:** 3-minute hard interrupt per run, `.tick.lock` file
|
||||
prevents duplicate ticks across processes, cron sessions pass
|
||||
`skip_memory=True` by default, and cron deliveries are framed with a
|
||||
header/footer instead of being mirrored into the target gateway
|
||||
session (keeps role alternation intact).
|
||||
|
||||
User docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/cron
|
||||
|
||||
### Curator (skill lifecycle)
|
||||
|
||||
Background maintenance for agent-created skills. Tracks usage, marks
|
||||
idle skills stale, archives stale ones, keeps a pre-run tar.gz backup
|
||||
so nothing is lost.
|
||||
|
||||
- **CLI:** `hermes curator <verb>` — `status`, `usage`, `run`, `pause`,
|
||||
`resume`, `pin`, `unpin`, `archive`, `restore`, `list-archived`, `prune`,
|
||||
`backup`, `rollback`.
|
||||
- **Slash:** `/curator <subcommand>` mirrors the CLI.
|
||||
- **Scope:** only touches skills with `created_by: "agent"` provenance.
|
||||
Bundled + hub-installed skills are off-limits. **Never deletes** —
|
||||
max destructive action is archive. Pinned skills are exempt from
|
||||
every auto-transition and every LLM review pass.
|
||||
- **Cost:** the deterministic inactivity/prune sweep runs for free. The
|
||||
aux-model "consolidate overlapping skills into umbrellas" pass is
|
||||
**off by default** — opt in with `curator.consolidate: true` or
|
||||
`hermes curator run --consolidate`. Routine background curation costs
|
||||
zero tokens.
|
||||
- **Telemetry:** sidecar at `~/.hermes/skills/.usage.json` holds
|
||||
per-skill `use_count`, `view_count`, `patch_count`,
|
||||
`last_activity_at`, `state`, `pinned`.
|
||||
|
||||
Config: `curator.*` (`enabled`, `interval_hours`, `min_idle_hours`,
|
||||
`stale_after_days`, `archive_after_days`, `backup.*`).
|
||||
User docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/curator
|
||||
|
||||
### Kanban (multi-agent work queue)
|
||||
|
||||
Durable SQLite board for multi-profile / multi-worker collaboration.
|
||||
Users drive it via `hermes kanban <verb>`; dispatcher-spawned workers
|
||||
see a focused `kanban_*` toolset gated by `HERMES_KANBAN_TASK`, and
|
||||
orchestrator profiles can opt into the broader `kanban` toolset. Normal
|
||||
sessions still have zero `kanban_*` schema footprint unless configured.
|
||||
|
||||
- **CLI verbs (common):** `init`, `create`, `list` (alias `ls`),
|
||||
`show`, `assign`, `link`, `unlink`, `comment`, `complete`, `block`,
|
||||
`unblock`, `archive`, `tail`. Less common: `watch`, `stats`, `runs`,
|
||||
`log`, `dispatch`, `daemon`, `gc`.
|
||||
- **Worker/orchestrator toolset:** `kanban_show`, `kanban_complete`,
|
||||
`kanban_block`, `kanban_heartbeat`, `kanban_comment`, `kanban_create`,
|
||||
`kanban_link`; profiles that explicitly enable the `kanban` toolset
|
||||
outside a dispatcher-spawned task also get `kanban_list` and
|
||||
`kanban_unblock` for board routing.
|
||||
- **Dispatcher** runs inside the gateway by default
|
||||
(`kanban.dispatch_in_gateway: true`) — reclaims stale claims,
|
||||
promotes ready tasks, atomically claims, spawns assigned profiles.
|
||||
Auto-blocks a task after `failure_limit` consecutive spawn failures
|
||||
(default 2; configurable via `kanban.failure_limit` or per-task
|
||||
`max_retries`).
|
||||
- **Isolation:** board is the hard boundary (workers get
|
||||
`HERMES_KANBAN_BOARD` pinned in env); tenant is a soft namespace
|
||||
within a board for workspace-path + memory-key isolation.
|
||||
|
||||
User docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban
|
||||
@@ -0,0 +1,150 @@
|
||||
# Hermes CLI Reference
|
||||
|
||||
Live sources when anything looks stale: `hermes --help`, `hermes <command> --help`,
|
||||
https://hermes-agent.nousresearch.com/docs/reference/cli-commands
|
||||
|
||||
### Global Flags
|
||||
|
||||
```
|
||||
hermes [flags] [command] (no subcommand = interactive chat)
|
||||
|
||||
--version, -V Show version
|
||||
-z, --oneshot PROMPT One-shot: print ONLY the final response (for scripts/pipes)
|
||||
-m MODEL --provider P Model/provider override for this invocation
|
||||
-t, --toolsets LIST Comma-separated toolsets for this invocation
|
||||
--resume, -r SESSION Resume session by ID or title
|
||||
--continue, -c [NAME] Resume by name, or most recent session
|
||||
--worktree, -w Isolated git worktree mode (parallel agents)
|
||||
--skills, -s SKILL Preload skills (comma-separate or repeat)
|
||||
--profile, -p NAME Use a named profile
|
||||
--yolo Skip dangerous command approval
|
||||
--tui / --cli Force the Ink TUI / classic REPL
|
||||
--ignore-rules Skip AGENTS.md/SOUL.md/memory/skill injection
|
||||
--safe-mode Disable ALL customizations (troubleshooting)
|
||||
--pass-session-id Include session ID in system prompt
|
||||
```
|
||||
|
||||
### Chat
|
||||
|
||||
```
|
||||
hermes chat [flags]
|
||||
-q, --query TEXT Single query, non-interactive
|
||||
--image PATH Attach a local image to a single query
|
||||
-Q, --quiet Suppress banner, spinner, tool previews
|
||||
--checkpoints Enable filesystem checkpoints (/rollback)
|
||||
--max-turns N Cap tool-calling iterations
|
||||
--source TAG Session source tag (default: cli)
|
||||
```
|
||||
(plus the global flags above)
|
||||
|
||||
### Configuration
|
||||
|
||||
```
|
||||
hermes setup [section] Wizard (model|tts|terminal|gateway|tools|agent)
|
||||
hermes model Interactive model/provider picker
|
||||
hermes fallback [add|remove|list] Fallback provider chain
|
||||
hermes config [show|edit|get|set|unset|path|env-path|check|migrate]
|
||||
hermes login / logout OAuth sign-in / clear stored auth
|
||||
hermes doctor [--fix] Check dependencies and config
|
||||
hermes status [--all] Component status
|
||||
```
|
||||
|
||||
### Tools & Skills
|
||||
|
||||
```
|
||||
hermes tools [list|enable NAME|disable NAME] Per-platform toolsets (curses UI with no args)
|
||||
|
||||
hermes skills list|browse|search QUERY|inspect ID
|
||||
hermes skills install ID Hub identifier OR a direct https://…/SKILL.md URL
|
||||
hermes skills config Enable/disable skills per platform
|
||||
hermes skills check|update|uninstall|publish PATH
|
||||
hermes skills tap add REPO Add a GitHub repo as a skill source
|
||||
hermes bundles Skill bundles (one /<name> alias loads several skills)
|
||||
```
|
||||
|
||||
### MCP Servers
|
||||
|
||||
```
|
||||
hermes mcp add NAME (--url or --command) | remove | list | test NAME
|
||||
hermes mcp catalog | install NAME Curated catalog install
|
||||
hermes mcp configure NAME Toggle tool selection
|
||||
hermes mcp serve Run Hermes as an MCP server
|
||||
```
|
||||
Details (transport, tool discovery, catalog): `references/native-mcp.md`.
|
||||
|
||||
### Gateway (Messaging Platforms)
|
||||
|
||||
```
|
||||
hermes gateway run|install|start|stop|restart|status|setup
|
||||
```
|
||||
|
||||
20+ platforms: Telegram, Discord, Slack, WhatsApp (Baileys + Business Cloud API), iMessage (Photon — `hermes photon setup`), Signal, Email, SMS, Matrix, Mattermost, Teams, LINE, SimpleX, ntfy, Google Chat, Home Assistant, DingTalk, Feishu, WeCom, Weixin, API Server, Webhooks. Open WebUI connects via the API Server adapter. Most adapters ship under `plugins/platforms/`.
|
||||
Docs: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/
|
||||
|
||||
### Sessions
|
||||
|
||||
```
|
||||
hermes sessions list|browse|rename ID TITLE|delete ID|export OUT|prune|stats
|
||||
```
|
||||
|
||||
### Cron / Webhooks
|
||||
|
||||
```
|
||||
hermes cron list|create SCHED|edit ID|pause|resume|run ID|remove|status
|
||||
Schedules: '30m', 'every 2h', '0 9 * * *', ISO timestamp
|
||||
hermes webhook subscribe NAME|list|remove NAME|test NAME
|
||||
```
|
||||
Webhook payloads/routes: `references/webhooks.md`.
|
||||
|
||||
### Profiles
|
||||
|
||||
```
|
||||
hermes profile list|create NAME (--clone|--clone-all|--clone-from)|use|show|delete
|
||||
hermes profile rename A B | alias NAME | export NAME | import FILE
|
||||
```
|
||||
|
||||
### Credentials & Pools
|
||||
|
||||
```
|
||||
hermes auth Interactive credential manager
|
||||
hermes auth add [PROVIDER] Add OAuth or API-key credential (nous, openai-codex, qwen-oauth, …)
|
||||
hermes auth list|remove P IDX|reset PROVIDER|status
|
||||
```
|
||||
Multiple credentials per provider form a pool that rotates automatically and skips exhausted keys.
|
||||
|
||||
### Other
|
||||
|
||||
```
|
||||
hermes desktop / gui Native desktop app
|
||||
hermes dashboard Web admin panel + embedded chat (--stop / --status)
|
||||
hermes proxy OpenAI-compatible local proxy backed by an OAuth provider
|
||||
hermes portal Quick setup / sign in via Nous Portal
|
||||
hermes kanban <verb> Multi-agent work-queue board
|
||||
hermes project Named multi-folder workspaces
|
||||
hermes skin list|use|set Switch/tweak skins (see references/themes.md)
|
||||
hermes pets <verb> Pet mascots (see references/petdex.md)
|
||||
hermes memory setup|status|off|reset Memory provider
|
||||
hermes secrets bitwarden|onepassword External secret stores
|
||||
hermes moa Mixture-of-Agents slots
|
||||
hermes hooks / security / backup / import / checkpoints / console
|
||||
hermes logs [-f] [errors] View agent/error logs
|
||||
hermes send One-off message through a gateway platform
|
||||
hermes pairing / plugins / insights / journey / computer-use
|
||||
hermes acp ACP server (IDE integration)
|
||||
hermes completion bash|zsh|fish
|
||||
hermes update / uninstall / claw migrate
|
||||
```
|
||||
|
||||
Plugin- and provider-supplied subcommands (e.g. `hermes photon setup`) only appear once their plugin is installed/active.
|
||||
|
||||
### Where to Find Things
|
||||
|
||||
| Looking for... | Location |
|
||||
|---|---|
|
||||
| Config options | `hermes config edit` · [Configuration docs](https://hermes-agent.nousresearch.com/docs/user-guide/configuration) |
|
||||
| Tools / toolsets | `hermes tools list` · [Tools reference](https://hermes-agent.nousresearch.com/docs/reference/tools-reference) |
|
||||
| Skills catalog | `hermes skills browse` · [Skills catalog](https://hermes-agent.nousresearch.com/docs/reference/skills-catalog) |
|
||||
| Provider setup | `hermes model` · [Providers guide](https://hermes-agent.nousresearch.com/docs/integrations/providers) |
|
||||
| Env variables | `hermes config env-path` · [Env vars reference](https://hermes-agent.nousresearch.com/docs/reference/environment-variables) |
|
||||
| Gateway logs | `~/.hermes/logs/gateway.log` (or `hermes logs`) |
|
||||
| Sessions | `hermes sessions browse` (reads state.db) |
|
||||
@@ -0,0 +1,89 @@
|
||||
# Configuration, Toolsets & Voice
|
||||
|
||||
Edit with `hermes config edit` or `hermes config set section.key value`.
|
||||
Full reference: https://hermes-agent.nousresearch.com/docs/user-guide/configuration
|
||||
|
||||
### Config Sections (most-used keys)
|
||||
|
||||
| Section | Key options |
|
||||
|---------|-------------|
|
||||
| `model` | `default`, `provider`, `base_url`, `api_key`, `context_length`, `aliases` |
|
||||
| `agent` | `max_turns` (90), `tool_use_enforcement`, `service_tier`, `verify_on_stop` |
|
||||
| `terminal` | `backend` (local/docker/ssh/modal/daytona/singularity), `cwd`, `timeout` (180) |
|
||||
| `compression` | `enabled`, `threshold` (0.50), `target_ratio` (0.20) |
|
||||
| `display` | `skin`, `interface` (cli/tui), `language`, `show_reasoning`, `show_cost`, `pet` |
|
||||
| `approvals` | `mode` (smart/manual/off), `timeout`, `cron_mode` |
|
||||
| `stt` | `enabled`, `provider` (local/groq/openai/mistral/elevenlabs/deepinfra) |
|
||||
| `tts` | `provider` (edge/elevenlabs/openai/minimax/mistral/neutts/gemini/piper/kittentts/deepinfra/xai) |
|
||||
| `memory` | `memory_enabled`, `user_profile_enabled`, `provider`, `write_approval` |
|
||||
| `security` | `redact_secrets`, `tirith_enabled`, `website_blocklist` |
|
||||
| `delegation` | `model`, `provider`, `max_concurrent_children`, `max_iterations` (50), `max_spawn_depth` |
|
||||
| `checkpoints` | `enabled`, `max_snapshots` (50) |
|
||||
| `curator` | `enabled`, `consolidate` (false, opt-in aux-model consolidation), `interval_hours`, `stale_after_days` |
|
||||
|
||||
`hermes config check` reports sections missing from an older config.
|
||||
|
||||
### Toolsets
|
||||
|
||||
Enable/disable via `hermes tools` (interactive) or `hermes tools enable/disable NAME`.
|
||||
Full enumeration: `TOOLSETS` dict in `toolsets.py` (`_HERMES_CORE_TOOLS` is the default bundle most platforms inherit).
|
||||
|
||||
| Toolset | What it provides |
|
||||
|---------|-----------------|
|
||||
| `web` / `search` | Web search + extraction / search-only subset |
|
||||
| `browser` | Browser automation (Browserbase, Camofox, or local Chromium) |
|
||||
| `terminal` | Shell commands and process management |
|
||||
| `file` | File read/write/search/patch |
|
||||
| `code_execution` | Sandboxed Python execution |
|
||||
| `coding` | Code-editing helpers (LSP-backed) |
|
||||
| `computer_use` | Desktop GUI control (cua-driver) |
|
||||
| `vision` | Image analysis |
|
||||
| `image_gen` | Image generation and image-to-image editing |
|
||||
| `video` / `video_gen` | Video analysis / video generation |
|
||||
| `x_search` | X (Twitter) search (X OAuth or API key) |
|
||||
| `tts` | Text-to-speech |
|
||||
| `skills` | Skill browsing and management |
|
||||
| `memory` | Persistent cross-session memory |
|
||||
| `session_search` | Search past conversations |
|
||||
| `context_engine` | Pluggable context-engine hooks |
|
||||
| `project` | Named multi-folder workspace tools |
|
||||
| `delegation` | Subagent task delegation |
|
||||
| `cronjob` | Scheduled task management |
|
||||
| `clarify` | Ask user clarifying questions |
|
||||
| `todo` | In-session task planning |
|
||||
| `kanban` | Multi-agent work-queue tools (gated to workers) |
|
||||
| `debugging` | Extra introspection tools (off by default) |
|
||||
| `safe` | Minimal low-risk toolset for locked-down sessions |
|
||||
| `spotify`, `homeassistant`, `discord`, `discord_admin`, `feishu_doc`, `feishu_drive`, `yuanbao` | Service integrations (gated on their credentials) |
|
||||
|
||||
Tool changes take effect on `/reset` (new session) — never mid-conversation, to preserve prompt caching.
|
||||
|
||||
## Voice
|
||||
|
||||
### STT (Voice → Text)
|
||||
|
||||
Voice messages from messaging platforms are auto-transcribed.
|
||||
|
||||
```yaml
|
||||
stt:
|
||||
enabled: true
|
||||
provider: local # local (faster-whisper, free) | groq | openai | mistral | elevenlabs | deepinfra
|
||||
local:
|
||||
model: base # tiny, base, small, medium, large-v3
|
||||
```
|
||||
|
||||
Auto-detect priority: local faster-whisper (`pip install faster-whisper`) → Groq (`GROQ_API_KEY`, free tier) → OpenAI (`VOICE_TOOLS_OPENAI_KEY`) → Mistral Voxtral (`MISTRAL_API_KEY`).
|
||||
|
||||
### TTS (Text → Voice)
|
||||
|
||||
| Provider | Env var | Free? |
|
||||
|----------|---------|-------|
|
||||
| Edge TTS (default) | None | Yes |
|
||||
| ElevenLabs | `ELEVENLABS_API_KEY` | Free tier |
|
||||
| OpenAI | `VOICE_TOOLS_OPENAI_KEY` | Paid |
|
||||
| MiniMax | `MINIMAX_API_KEY` | Paid |
|
||||
| Mistral | `MISTRAL_API_KEY` | Paid |
|
||||
| Gemini | `GOOGLE_API_KEY` | Free tier |
|
||||
| NeuTTS / Piper / KittenTTS (local) | None | Free |
|
||||
|
||||
Voice commands: `/voice on` (voice-to-voice), `/voice tts` (always voice), `/voice off`.
|
||||
@@ -0,0 +1,144 @@
|
||||
# Contributor Quick Reference
|
||||
|
||||
For occasional contributors and PR authors. Full developer docs: https://hermes-agent.nousresearch.com/docs/developer-guide/
|
||||
|
||||
### Project Layout
|
||||
|
||||
```
|
||||
hermes-agent/
|
||||
├── run_agent.py # AIAgent — core conversation loop
|
||||
├── model_tools.py # Tool discovery and dispatch
|
||||
├── toolsets.py # Toolset definitions
|
||||
├── cli.py # Interactive CLI (HermesCLI)
|
||||
├── hermes_state.py # SQLite session store
|
||||
├── agent/ # Prompt builder, context compression, memory, model routing, credential pooling, skill dispatch
|
||||
├── hermes_cli/ # CLI subcommands, config, setup, commands
|
||||
│ ├── commands.py # Slash command registry (CommandDef)
|
||||
│ ├── config.py # DEFAULT_CONFIG, env var definitions
|
||||
│ └── main.py # CLI entry point and argparse
|
||||
├── tools/ # One file per tool
|
||||
│ └── registry.py # Central tool registry
|
||||
├── gateway/ # Messaging gateway
|
||||
│ └── platforms/ # Platform adapters (telegram, discord, etc.)
|
||||
├── cron/ # Job scheduler
|
||||
├── tests/ # Extensive pytest suite (run via scripts/run_tests.sh)
|
||||
└── website/ # Docusaurus docs site
|
||||
```
|
||||
|
||||
Config: `~/.hermes/config.yaml` (settings), `~/.hermes/.env` (API keys) — both under `$HERMES_HOME` when it is set.
|
||||
|
||||
### Adding a Tool
|
||||
|
||||
Two files. Auto-discovery imports any `tools/*.py` with a top-level
|
||||
`registry.register()` call, but a tool is only *exposed* to an agent once
|
||||
its name appears in a toolset.
|
||||
|
||||
**1. Create `tools/your_tool.py`:**
|
||||
```python
|
||||
import json, os
|
||||
from tools.registry import registry
|
||||
|
||||
def check_requirements() -> bool:
|
||||
return bool(os.getenv("EXAMPLE_API_KEY"))
|
||||
|
||||
def example_tool(param: str, task_id: str = None) -> str:
|
||||
return json.dumps({"success": True, "data": "..."})
|
||||
|
||||
registry.register(
|
||||
name="example_tool",
|
||||
toolset="example",
|
||||
schema={"name": "example_tool", "description": "...", "parameters": {...}},
|
||||
handler=lambda args, **kw: example_tool(
|
||||
param=args.get("param", ""), task_id=kw.get("task_id")),
|
||||
check_fn=check_requirements,
|
||||
requires_env=["EXAMPLE_API_KEY"],
|
||||
)
|
||||
```
|
||||
|
||||
**2. Wire it into a toolset in `toolsets.py`** — add the name to
|
||||
`_HERMES_CORE_TOOLS` (every platform) or to a specific toolset.
|
||||
|
||||
All handlers must return JSON strings. Use `get_hermes_home()` for paths,
|
||||
never hardcode `~/.hermes`. For custom/local-only tools, write a plugin in
|
||||
`~/.hermes/plugins/` instead of editing core — see the developer docs.
|
||||
|
||||
### Adding a Slash Command
|
||||
|
||||
1. Add `CommandDef` to `COMMAND_REGISTRY` in `hermes_cli/commands.py`
|
||||
2. Add handler in `cli.py` → `process_command()`
|
||||
3. (Optional) Add gateway handler in `gateway/run.py`
|
||||
|
||||
All consumers (help text, autocomplete, Telegram menu, Slack mapping) derive from the central registry automatically.
|
||||
|
||||
### Agent Loop (High Level)
|
||||
|
||||
```
|
||||
run_conversation():
|
||||
1. Build system prompt
|
||||
2. Loop while iterations < max:
|
||||
a. Call LLM (OpenAI-format messages + tool schemas)
|
||||
b. If tool_calls → dispatch each via handle_function_call() → append results → continue
|
||||
c. If text response → return
|
||||
3. Context compression triggers automatically near token limit
|
||||
```
|
||||
|
||||
### Testing
|
||||
|
||||
Use the canonical runner — it enforces CI-parity (hermetic `env -i`, unset
|
||||
credentials, TZ=UTC, per-file subprocess isolation via
|
||||
`scripts/run_tests_parallel.py` — no xdist, worker count auto-scaled):
|
||||
|
||||
```bash
|
||||
scripts/run_tests.sh # full suite
|
||||
scripts/run_tests.sh tests/tools/ # one directory
|
||||
scripts/run_tests.sh tests/tools/test_x.py # one file
|
||||
scripts/run_tests.sh -v --tb=long # pass-through pytest flags
|
||||
```
|
||||
|
||||
- Tests auto-redirect `HERMES_HOME` to temp dirs — never touch real `~/.hermes/`.
|
||||
- The script probes `.venv`, then `venv`, then the shared worktree venv.
|
||||
- **Windows:** the wrapper is POSIX-only; see `references/windows-quirks.md`
|
||||
for the direct-pytest workaround.
|
||||
|
||||
**Cross-platform test guards:** tests using POSIX-only syscalls need a skip marker. Common ones already in the codebase:
|
||||
- Symlink creation → `@pytest.mark.skipif(sys.platform == "win32", reason="Symlinks require elevated privileges on Windows")` (see `tests/cron/test_cron_script.py`)
|
||||
- POSIX file modes (0o600, etc.) → `@pytest.mark.skipif(sys.platform.startswith("win"), reason="POSIX mode bits not enforced on Windows")` (see `tests/hermes_cli/test_auth_toctou_file_modes.py`)
|
||||
- `signal.SIGALRM` → Unix-only (per-test timeouts no longer use it directly; see the win32 timeout-method shim in `tests/conftest.py::pytest_configure`)
|
||||
- Live Winsock / Windows-specific regression tests → `@pytest.mark.skipif(sys.platform != "win32", reason="Windows-specific regression")`
|
||||
|
||||
**Monkeypatching `sys.platform` is not enough** when the code under test also calls `platform.system()` / `platform.release()` / `platform.mac_ver()`. Those functions re-read the real OS independently, so a test that sets `sys.platform = "linux"` on a Windows runner will still see `platform.system() == "Windows"` and route through the Windows branch. Patch all three together:
|
||||
|
||||
```python
|
||||
monkeypatch.setattr(sys, "platform", "linux")
|
||||
monkeypatch.setattr(platform, "system", lambda: "Linux")
|
||||
monkeypatch.setattr(platform, "release", lambda: "6.8.0-generic")
|
||||
```
|
||||
|
||||
See `tests/agent/test_prompt_builder.py::TestEnvironmentHints` for a worked example.
|
||||
|
||||
### System prompt's execution-environment block
|
||||
|
||||
Factual host/backend guidance (OS, `$HOME`, cwd, terminal backend, shell)
|
||||
is emitted by `agent/prompt_builder.py::build_environment_hints()`. The key
|
||||
invariant for prompt authors: with a **remote** terminal backend
|
||||
(`docker, singularity, modal, daytona, ssh, managed_modal`), host info is
|
||||
suppressed and *every* file tool runs inside the backend container — the
|
||||
prompt must never describe the host the agent can't touch.
|
||||
|
||||
### Commit Conventions
|
||||
|
||||
```
|
||||
type: concise subject line
|
||||
|
||||
Optional body.
|
||||
```
|
||||
|
||||
Types: `fix:`, `feat:`, `refactor:`, `docs:`, `chore:`
|
||||
|
||||
### Key Rules
|
||||
|
||||
- **Never break prompt caching** — don't change context, tools, or system prompt mid-conversation
|
||||
- **Message role alternation** — never two assistant or two user messages in a row
|
||||
- Use `get_hermes_home()` from `hermes_constants` for all paths (profile-safe)
|
||||
- Config values go in `config.yaml`, secrets go in `.env`
|
||||
- New tools need a `check_fn` so they only appear when requirements are met
|
||||
@@ -0,0 +1,99 @@
|
||||
# delegate_task: diagnosing "my batch was capped"
|
||||
|
||||
When a user reports `delegate_task` ran fewer subagents than they asked for
|
||||
(e.g. "I set max_concurrent_children: 15 but only 9 ran"), there are exactly
|
||||
**three** code paths in Hermes that cap a batch. If none of them fired, the
|
||||
cap came from the **model itself** — not from Hermes — and the user's
|
||||
narration of "the runtime caps at N" is the model rationalising its own
|
||||
choice.
|
||||
|
||||
## The three real caps in Hermes
|
||||
|
||||
All resolved through `tools.delegate_tool._get_max_concurrent_children()`,
|
||||
which reads `delegation.max_concurrent_children` from `config.yaml`
|
||||
(env fallback `DELEGATION_MAX_CONCURRENT_CHILDREN`, default 3). Floor of 1.
|
||||
**No hard ceiling.**
|
||||
|
||||
1. **Per-call hard reject** — `tools/delegate_tool.py` (~line 1953).
|
||||
If `len(tasks) > max_children`, the call returns a `tool_error` with the
|
||||
exact message: `"Too many tasks: {N} provided, but
|
||||
max_concurrent_children is {M}. ..."` The model sees this as a failed
|
||||
tool call and usually retries with fewer tasks.
|
||||
|
||||
2. **Per-turn truncator** — `run_agent.py::AIAgent._cap_delegate_task_calls`
|
||||
(~line 5708). If the model emits *multiple separate* `delegate_task`
|
||||
tool_calls in a single assistant turn, the count of those calls is
|
||||
truncated to `max_children`. Logs as
|
||||
`Truncated N excess delegate_task call(s) to enforce
|
||||
max_concurrent_children=M limit` at WARNING.
|
||||
|
||||
3. **Cost-warning** — same `_get_max_concurrent_children()`. When the
|
||||
resolved value is `> 10`, logs once at WARNING:
|
||||
`delegation.max_concurrent_children=N: each child consumes API tokens
|
||||
independently. High values multiply cost linearly.` This is **just a
|
||||
log line** — it does not cap anything. Easy to mis-read as "Hermes is
|
||||
refusing my value."
|
||||
|
||||
## Diagnostic recipe
|
||||
|
||||
When a user says "delegate is capped at N":
|
||||
|
||||
```bash
|
||||
# 1. What does the loaded config actually say?
|
||||
hermes config get delegation.max_concurrent_children
|
||||
|
||||
# 2. Did Hermes' truncator or rejector actually fire?
|
||||
grep -E "Truncated.*delegate_task|Too many tasks" ~/.hermes/logs/agent.log | tail
|
||||
# If neither line appears, neither cap path executed.
|
||||
|
||||
# 3. Confirm the resolver returns what config says (in venv with hermes on path)
|
||||
python -c "from tools.delegate_tool import _get_max_concurrent_children; \
|
||||
print(_get_max_concurrent_children())"
|
||||
```
|
||||
|
||||
If config and `_get_max_concurrent_children()` agree, and neither log line
|
||||
appears, **the cap is the model**, not Hermes.
|
||||
|
||||
## Why models self-limit batches
|
||||
|
||||
Reasoning models (Claude Opus/Sonnet, GPT-5, Grok-4) routinely trim a
|
||||
13- or 15-task batch to a "rounder" number (5, 8, 9, 10) when their
|
||||
internal reasoning says the coordination cost outweighs parallelism. The
|
||||
cost-warning log line printed at startup *reinforces* this — the model
|
||||
reads its own reasoning trace and sees "each child consumes API tokens
|
||||
independently" and concludes a smaller batch is "more responsible."
|
||||
|
||||
The model will then narrate the choice as "the runtime caps at 9" or
|
||||
"despite the config saying 15, max parallel is 9," which is **not true**
|
||||
— it's post-hoc rationalisation. Calling this out to the user is fine;
|
||||
it is a real, well-known reasoning-model failure mode (face-saving
|
||||
attribution to the system rather than admitting a self-imposed limit).
|
||||
|
||||
## How to actually force N parallel children
|
||||
|
||||
Tell the model explicitly in the prompt:
|
||||
|
||||
> "Send all 13 tasks in **one** `delegate_task` call with a `tasks` array
|
||||
> of 13 items. Do not split into multiple calls. The runtime supports
|
||||
> this; `delegation.max_concurrent_children` is set to 15."
|
||||
|
||||
If the model still trims, use `execute_code` to construct the `tasks`
|
||||
list deterministically and call the tool with that exact list — the
|
||||
model is then merely a courier and is far less likely to second-guess
|
||||
the count. Or use a different model: smaller / less-reasoning-heavy
|
||||
models trim less aggressively in practice.
|
||||
|
||||
## Pitfalls / gotchas
|
||||
|
||||
- **`max_concurrent_children` is a per-parent cap, not a global cap.**
|
||||
Confirmed in `ui-tui/src/components/appChrome.tsx`. Two different
|
||||
parents can each spawn `max_children` workers concurrently.
|
||||
- **`subagent_auto_approve: false` does not cap concurrency.** It only
|
||||
controls whether children inherit yolo / approval bypass. Don't mistake
|
||||
it for a throttle.
|
||||
- **The cost-warning log fires on every call** when the value is > 10.
|
||||
Don't take its presence as evidence that anything was capped — only
|
||||
the `Truncated...` and `Too many tasks` lines indicate actual capping.
|
||||
- **Don't suggest reverting `max_concurrent_children` to fix this.** The
|
||||
user set it deliberately; the fix is to push back on the model, not
|
||||
the config.
|
||||
@@ -0,0 +1,152 @@
|
||||
# Desktop App Plugins — UI Panes, Commands, Widgets
|
||||
|
||||
Write plugins for the Hermes desktop app: statusbar items, layout panes,
|
||||
command-palette commands, keybinds, routes, and themes. A plugin is a single
|
||||
plain-JavaScript ESM file the app loads at runtime — no build step, no repo
|
||||
changes. A plugin can also talk to its own Python backend namespace
|
||||
(`ctx.rest`/`ctx.socket` → `/api/plugins/<id>`); the general Python plugin
|
||||
system (`~/.hermes/plugins/`) is otherwise documented separately.
|
||||
|
||||
Full human reference (every export, area payloads, backend, security):
|
||||
`website/docs/developer-guide/desktop-plugin-sdk.md`.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user asks for a new desktop UI element (a pane, a statusbar widget, a
|
||||
dashboard, a command) without modifying the app itself.
|
||||
- You want to surface data you compute (via gateway RPC) inside the app.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- The Hermes desktop app (it loads plugins; the CLI/gateway alone does not).
|
||||
- Write access to `$HERMES_HOME/desktop-plugins/` (usually
|
||||
`~/.hermes/desktop-plugins/`).
|
||||
|
||||
## How to Run
|
||||
|
||||
1. Create `$HERMES_HOME/desktop-plugins/<name>/plugin.js` from
|
||||
`templates/plugin.js` (in this skill directory) — that's
|
||||
`~/.hermes/...` by default, or `~/.hermes/profiles/<profile>/...` under a
|
||||
named profile. Keep `<name>` equal to the plugin `id`.
|
||||
2. The desktop app watches that directory: the plugin loads within a few
|
||||
seconds of the file landing, and every later save hot-reloads it in
|
||||
place. No reload step. (Fallback if it doesn't appear: ⌘K →
|
||||
**Reload desktop plugins**.)
|
||||
3. If loading fails the app shows a toast naming the error — fix the file
|
||||
and save again.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
The ONLY import surface is `@hermes/plugin-sdk` (plus `react` /
|
||||
`react/jsx-runtime`, which resolve to the app's own React — write UI with
|
||||
`jsx()` calls, not JSX syntax; the file is not compiled).
|
||||
|
||||
- `host.state.*` — readonly reactive atoms: `activeSessionId`, `cwd`,
|
||||
`gateway`, `model`, `profile`, `viewport`. Read with `.get()` in handlers,
|
||||
`useValue(atom)` in components.
|
||||
- `host.request(method, params)` — gateway JSON-RPC (sessions, config,
|
||||
skills, cron — everything the app uses).
|
||||
- `host.onEvent(type, fn)` — live gateway events (`'*'` for all). Returns a
|
||||
disposer.
|
||||
- `host.notify({ kind, message })`, `host.navigate(path)`, `host.logs(...)`,
|
||||
`host.status()`, `haptic('tap')`.
|
||||
- `ctx.register({ id, area, order?, render?, data? })` — contribute UI.
|
||||
Key areas: `'statusBar.right'`/`'statusBar.left'` (chips),
|
||||
`'panes'` (layout zones — set `title` and
|
||||
`data: { placement, dock?, width?, height? }`; the pane auto-joins a
|
||||
matching zone), `PALETTE_AREA` (⌘K commands), `KEYBINDS_AREA` (rebindable
|
||||
actions).
|
||||
- Pane placement: `placement: 'left'|'right'|'bottom'|'main'` is the
|
||||
semantic role — the pane stacks (tabs) with existing panes of that role.
|
||||
To land on a specific EDGE instead, add `dock: { pane, pos }` — the same
|
||||
gesture as dragging onto a pane's drop chip. `pane` is any pane id
|
||||
(`workspace` is the main thread; also `sessions`, `terminal`, `files`,
|
||||
`review`, `logs`), `pos` is `'top'|'bottom'|'left'|'right'|'center'`.
|
||||
E.g. "below the conversation" = `dock: { pane: 'workspace', pos: 'bottom' }`
|
||||
— declare a `height` (e.g. `'200px'`) so it doesn't take half the zone.
|
||||
- Full PAGES: register `area: ROUTES_AREA` with `data: { path: '/my-page' }`
|
||||
and a `render` — the page mounts in the workspace (main) pane like any
|
||||
built-in view. Make it reachable with a sidebar nav row:
|
||||
`ctx.register({ id: 'nav', area: SIDEBAR_NAV_AREA, data: { path: '/my-page', label: 'My Page', codicon: 'project' } })`
|
||||
(renders below Artifacts, lights up at the route) — and/or a
|
||||
`PALETTE_AREA` command calling `host.navigate('/my-page')`.
|
||||
- `ctx.storage.get/set/remove` — persistence namespaced to your plugin.
|
||||
- `ctx.i18n.register({ en, ja, ... })` — ship your OWN locale bundles, scoped
|
||||
to your plugin (never edit core `en.ts`). Values are literal strings or
|
||||
interpolator functions; nested trees are addressed by dot-path. Read them
|
||||
reactively in components with `usePluginI18n(id)` returning `t('key', ...args)`
|
||||
(re-renders on a locale switch), or via `ctx.i18n.t` in handlers/stores.
|
||||
Resolution follows the app's active locale, then your `en`, then the raw key.
|
||||
- Data: `useQuery`/`useMutation`/`useQueryClient`/`queryClient` (the app's ONE
|
||||
React Query client — cache, dedupe, `refetchInterval`, invalidate like core;
|
||||
never hand-roll a poll loop), plus `atom`/`computed` for plugin-local state.
|
||||
- Backend: if the plugin ships a Python `plugin_api.py` (under
|
||||
`~/.hermes/plugins/<id>/dashboard/`, manifest `"api": "plugin_api.py"`), reach
|
||||
it with `ctx.rest('/path', { method?, body?, timeoutMs? })` and its live twin
|
||||
`ctx.socket('/events', onMessage)` — both scoped to `/api/plugins/<id>` by
|
||||
construction (traversal rejected). `ctx.socket` is a **no-op on OAuth
|
||||
remotes**, so always keep a polling fallback. The Python backend is imported
|
||||
only when the plugin is in `plugins.enabled` in `config.yaml` (separate from
|
||||
the in-app enable toggle). For gateway-wide data use `host.request` /
|
||||
`host.onEvent` instead.
|
||||
- `Contribute` (mount-scoped): render `jsx(Contribute, { area, id, children })`
|
||||
inside a component so page-owned chrome (e.g. a titlebar control in
|
||||
`TITLEBAR_AREAS.center`) leaves when the page unmounts — `ctx.register` is for
|
||||
permanent contributions.
|
||||
- `defaultEnabled: false` on the default export ships an opt-in plugin: it
|
||||
inventories in Settings → Plugins, off until the user flips it on.
|
||||
- Users manage plugins in Settings → Plugins (enable/disable live, reveal
|
||||
folder). A disabled plugin stays disabled across restarts — don't fight
|
||||
it; the user turned you off.
|
||||
- UI: the app's design language, importable directly — `Button`, `Input`,
|
||||
`Textarea`, `Select*`, `Switch`, `Checkbox`, `SegmentedControl`, `Tabs*`,
|
||||
`Dialog*`, `ConfirmDialog`, `DropdownMenu*`, `ContextMenu*`, `Popover*`,
|
||||
`Tip`/`Tooltip*`, `Badge`, `Kbd`/`KbdGroup`, `SearchField`, `ScrollArea`,
|
||||
`Separator`, `Skeleton`, `GlyphSpinner`, `EmptyState`, `ErrorState`,
|
||||
`CopyButton`, `StatusDot`, `LogView`, `Codicon`, `DecodeText`, plus `cn`
|
||||
and `icons.*`. Prefer these over hand-rolled elements so the plugin looks
|
||||
native; style with theme vars, never hardcoded colors.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Pick a short kebab-case `id`; the folder name must match.
|
||||
2. Start from `templates/plugin.js`; keep the default export shape
|
||||
(`{ id, name, register(ctx) }`).
|
||||
3. For a pane, register `area: 'panes'` with a `placement` hint and a
|
||||
`render` returning your component — the app places it into a sensible
|
||||
zone automatically; the user can drag it anywhere afterwards.
|
||||
4. Fetch data with `host.request` and/or subscribe with `host.onEvent`;
|
||||
never poll faster than a few seconds.
|
||||
5. Write the file with your file tools, then ask the user to run
|
||||
**Reload desktop plugins** from ⌘K.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- NEVER hardcode colors or backgrounds (`#000`, `black`, `rgb(...)`). Panes
|
||||
already sit on the app's editor background — leave the background alone
|
||||
and use theme variables for everything else: `var(--ui-text-secondary)`,
|
||||
`var(--ui-text-quaternary)`, `var(--ui-stroke-secondary)`,
|
||||
`var(--ui-accent)`. For canvas drawing, resolve them once with
|
||||
`getComputedStyle(canvas).getPropertyValue('--ui-accent')`.
|
||||
- Reference only what you imported — a component you forgot to import
|
||||
(e.g. `StatusDot`) is a ReferenceError at render. Double-check every
|
||||
identifier in your `jsx()` calls appears in the import line.
|
||||
- Canvas panes MUST track their container with a `ResizeObserver` and
|
||||
re-size the canvas (width/height attributes, not just CSS) — panes resize
|
||||
constantly (sash drags, layout switches); a mount-time-only size leaves
|
||||
blank space or blurry scaling.
|
||||
- JSX syntax will not parse — the file loads uncompiled. Use
|
||||
`jsx('div', { children: ... })` from `react/jsx-runtime`.
|
||||
- Do not import anything except `@hermes/plugin-sdk`, `react`, and
|
||||
`react/jsx-runtime`; other specifiers fail to resolve.
|
||||
- Handlers must read state imperatively (`$atom.get()`), never from render
|
||||
closures — rapid events will otherwise see stale values.
|
||||
- Keep components small; subscribe (`useValue`) only in the leaf that
|
||||
renders the value.
|
||||
|
||||
## Verification
|
||||
|
||||
- The plugin's UI appears after **Reload desktop plugins**.
|
||||
- No error toast ("Plugin <name> failed to load") appears; if it does, the
|
||||
message names the failure — fix and reload.
|
||||
- For panes: the new zone is visible and draggable like any core pane.
|
||||
@@ -0,0 +1,344 @@
|
||||
# Native MCP Client
|
||||
|
||||
Hermes Agent has a built-in MCP client that connects to MCP servers at startup, discovers their tools, and makes them available as first-class tools the agent can call directly. No bridge CLI needed -- tools from MCP servers appear alongside built-in tools like `terminal`, `read_file`, etc.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this whenever you want to:
|
||||
- Connect to MCP servers and use their tools from within Hermes Agent
|
||||
- Add external capabilities (filesystem access, GitHub, databases, APIs) via MCP
|
||||
- Run local stdio-based MCP servers (npx, uvx, or any command)
|
||||
- Connect to remote HTTP/StreamableHTTP MCP servers
|
||||
- Have MCP tools auto-discovered and available in every conversation
|
||||
|
||||
For ad-hoc, one-off MCP tool calls from the terminal without configuring anything, see the `mcporter` skill instead.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **mcp Python package** -- optional dependency; install with `pip install mcp`. If not installed, MCP support is silently disabled.
|
||||
- **Node.js** -- required for `npx`-based MCP servers (most community servers)
|
||||
- **uv** -- required for `uvx`-based MCP servers (Python-based servers)
|
||||
|
||||
Install the MCP SDK:
|
||||
|
||||
```bash
|
||||
pip install mcp
|
||||
# or, if using uv:
|
||||
uv pip install mcp
|
||||
```
|
||||
|
||||
## Quick Start
|
||||
|
||||
Add MCP servers to `~/.hermes/config.yaml` under the `mcp_servers` key:
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
time:
|
||||
command: "uvx"
|
||||
args: ["mcp-server-time"]
|
||||
```
|
||||
|
||||
Restart Hermes Agent. On startup it will:
|
||||
1. Connect to the server
|
||||
2. Discover available tools
|
||||
3. Register them with the prefix `mcp_time_*`
|
||||
4. Inject them into all platform toolsets
|
||||
|
||||
You can then use the tools naturally -- just ask the agent to get the current time.
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
Each entry under `mcp_servers` is a server name mapped to its config. There are two transport types: **stdio** (command-based) and **HTTP** (url-based).
|
||||
|
||||
### Stdio Transport (command + args)
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
server_name:
|
||||
command: "npx" # (required) executable to run
|
||||
args: ["-y", "pkg-name"] # (optional) command arguments, default: []
|
||||
env: # (optional) environment variables for the subprocess
|
||||
SOME_API_KEY: "value"
|
||||
timeout: 120 # (optional) per-tool-call timeout in seconds, default: 120
|
||||
connect_timeout: 60 # (optional) initial connection timeout in seconds, default: 60
|
||||
```
|
||||
|
||||
### HTTP Transport (url)
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
server_name:
|
||||
url: "https://my-server.example.com/mcp" # (required) server URL
|
||||
headers: # (optional) HTTP headers
|
||||
Authorization: "Bearer sk-..."
|
||||
timeout: 180 # (optional) per-tool-call timeout in seconds, default: 120
|
||||
connect_timeout: 60 # (optional) initial connection timeout in seconds, default: 60
|
||||
```
|
||||
|
||||
### All Config Options
|
||||
|
||||
| Option | Type | Default | Description |
|
||||
|-------------------|--------|---------|---------------------------------------------------|
|
||||
| `command` | string | -- | Executable to run (stdio transport, required) |
|
||||
| `args` | list | `[]` | Arguments passed to the command |
|
||||
| `env` | dict | `{}` | Extra environment variables for the subprocess |
|
||||
| `url` | string | -- | Server URL (HTTP transport, required) |
|
||||
| `headers` | dict | `{}` | HTTP headers sent with every request |
|
||||
| `timeout` | int | `120` | Per-tool-call timeout in seconds |
|
||||
| `connect_timeout` | int | `60` | Timeout for initial connection and discovery |
|
||||
|
||||
Note: A server config must have either `command` (stdio) or `url` (HTTP), not both.
|
||||
|
||||
## How It Works
|
||||
|
||||
### Startup Discovery
|
||||
|
||||
When Hermes Agent starts, `discover_mcp_tools()` is called during tool initialization:
|
||||
|
||||
1. Reads `mcp_servers` from `~/.hermes/config.yaml`
|
||||
2. For each server, spawns a connection in a dedicated background event loop
|
||||
3. Initializes the MCP session and calls `list_tools()` to discover available tools
|
||||
4. Registers each tool in the Hermes tool registry
|
||||
|
||||
### Tool Naming Convention
|
||||
|
||||
MCP tools are registered with the naming pattern:
|
||||
|
||||
```
|
||||
mcp_{server_name}_{tool_name}
|
||||
```
|
||||
|
||||
Hyphens and dots in names are replaced with underscores for LLM API compatibility.
|
||||
|
||||
Examples:
|
||||
- Server `filesystem`, tool `read_file` → `mcp_filesystem_read_file`
|
||||
- Server `github`, tool `list-issues` → `mcp_github_list_issues`
|
||||
- Server `my-api`, tool `fetch.data` → `mcp_my_api_fetch_data`
|
||||
|
||||
### Auto-Injection
|
||||
|
||||
After discovery, MCP tools are automatically injected into all `hermes-*` platform toolsets (CLI, Discord, Telegram, etc.). This means MCP tools are available in every conversation without any additional configuration.
|
||||
|
||||
### Connection Lifecycle
|
||||
|
||||
- Each server runs as a long-lived asyncio Task in a background daemon thread
|
||||
- Connections persist for the lifetime of the agent process
|
||||
- If a connection drops, automatic reconnection with exponential backoff kicks in (up to 5 retries, max 60s backoff)
|
||||
- On agent shutdown, all connections are gracefully closed
|
||||
|
||||
### Idempotency
|
||||
|
||||
`discover_mcp_tools()` is idempotent -- calling it multiple times only connects to servers that aren't already connected. Failed servers are retried on subsequent calls.
|
||||
|
||||
## Transport Types
|
||||
|
||||
### Stdio Transport
|
||||
|
||||
The most common transport. Hermes launches the MCP server as a subprocess and communicates over stdin/stdout.
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
filesystem:
|
||||
command: "npx"
|
||||
args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]
|
||||
```
|
||||
|
||||
The subprocess inherits a **filtered** environment (see Security section below) plus any variables you specify in `env`.
|
||||
|
||||
### HTTP / StreamableHTTP Transport
|
||||
|
||||
For remote or shared MCP servers. Requires the `mcp` package to include HTTP client support (`mcp.client.streamable_http`).
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
remote_api:
|
||||
url: "https://mcp.example.com/mcp"
|
||||
headers:
|
||||
Authorization: "Bearer sk-..."
|
||||
```
|
||||
|
||||
If HTTP support is not available in your installed `mcp` version, the server will fail with an ImportError and other servers will continue normally.
|
||||
|
||||
## Security
|
||||
|
||||
### Environment Variable Filtering
|
||||
|
||||
For stdio servers, Hermes does NOT pass your full shell environment to MCP subprocesses. Only safe baseline variables are inherited:
|
||||
|
||||
- `PATH`, `HOME`, `USER`, `LANG`, `LC_ALL`, `TERM`, `SHELL`, `TMPDIR`
|
||||
- Any `XDG_*` variables
|
||||
|
||||
All other environment variables (API keys, tokens, secrets) are excluded unless you explicitly add them via the `env` config key. This prevents accidental credential leakage to untrusted MCP servers.
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
github:
|
||||
command: "npx"
|
||||
args: ["-y", "@modelcontextprotocol/server-github"]
|
||||
env:
|
||||
# Only this token is passed to the subprocess
|
||||
GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_..."
|
||||
```
|
||||
|
||||
### Credential Stripping in Error Messages
|
||||
|
||||
If an MCP tool call fails, any credential-like patterns in the error message are automatically redacted before being shown to the LLM. This covers:
|
||||
|
||||
- GitHub PATs (`ghp_...`)
|
||||
- OpenAI-style keys (`sk-...`)
|
||||
- Bearer tokens
|
||||
- Generic `token=`, `key=`, `API_KEY=`, `password=`, `secret=` patterns
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### "MCP SDK not available -- skipping MCP tool discovery"
|
||||
|
||||
The `mcp` Python package is not installed. Install it:
|
||||
|
||||
```bash
|
||||
pip install mcp
|
||||
```
|
||||
|
||||
### "No MCP servers configured"
|
||||
|
||||
No `mcp_servers` key in `~/.hermes/config.yaml`, or it's empty. Add at least one server.
|
||||
|
||||
### "Failed to connect to MCP server 'X'"
|
||||
|
||||
Common causes:
|
||||
- **Command not found**: The `command` binary isn't on PATH. Ensure `npx`, `uvx`, or the relevant command is installed.
|
||||
- **Package not found**: For npx servers, the npm package may not exist or may need `-y` in args to auto-install.
|
||||
- **Timeout**: The server took too long to start. Increase `connect_timeout`.
|
||||
- **Port conflict**: For HTTP servers, the URL may be unreachable.
|
||||
|
||||
### "MCP server 'X' requires HTTP transport but mcp.client.streamable_http is not available"
|
||||
|
||||
Your `mcp` package version doesn't include HTTP client support. Upgrade:
|
||||
|
||||
```bash
|
||||
pip install --upgrade mcp
|
||||
```
|
||||
|
||||
### Tools not appearing
|
||||
|
||||
- Check that the server is listed under `mcp_servers` (not `mcp` or `servers`)
|
||||
- Ensure the YAML indentation is correct
|
||||
- Look at Hermes Agent startup logs for connection messages
|
||||
- Tool names are prefixed with `mcp_{server}_{tool}` -- look for that pattern
|
||||
|
||||
### Connection keeps dropping
|
||||
|
||||
The client retries up to 5 times with exponential backoff (1s, 2s, 4s, 8s, 16s, capped at 60s). If the server is fundamentally unreachable, it gives up after 5 attempts. Check the server process and network connectivity.
|
||||
|
||||
## Examples
|
||||
|
||||
### Time Server (uvx)
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
time:
|
||||
command: "uvx"
|
||||
args: ["mcp-server-time"]
|
||||
```
|
||||
|
||||
Registers tools like `mcp_time_get_current_time`.
|
||||
|
||||
### Filesystem Server (npx)
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
filesystem:
|
||||
command: "npx"
|
||||
args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/documents"]
|
||||
timeout: 30
|
||||
```
|
||||
|
||||
Registers tools like `mcp_filesystem_read_file`, `mcp_filesystem_write_file`, `mcp_filesystem_list_directory`.
|
||||
|
||||
### GitHub Server with Authentication
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
github:
|
||||
command: "npx"
|
||||
args: ["-y", "@modelcontextprotocol/server-github"]
|
||||
env:
|
||||
GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_xxxxxxxxxxxxxxxxxxxx"
|
||||
timeout: 60
|
||||
```
|
||||
|
||||
Registers tools like `mcp_github_list_issues`, `mcp_github_create_pull_request`, etc.
|
||||
|
||||
### Remote HTTP Server
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
company_api:
|
||||
url: "https://mcp.mycompany.com/v1/mcp"
|
||||
headers:
|
||||
Authorization: "Bearer sk-xxxxxxxxxxxxxxxxxxxx"
|
||||
X-Team-Id: "engineering"
|
||||
timeout: 180
|
||||
connect_timeout: 30
|
||||
```
|
||||
|
||||
### Multiple Servers
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
time:
|
||||
command: "uvx"
|
||||
args: ["mcp-server-time"]
|
||||
|
||||
filesystem:
|
||||
command: "npx"
|
||||
args: ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
|
||||
|
||||
github:
|
||||
command: "npx"
|
||||
args: ["-y", "@modelcontextprotocol/server-github"]
|
||||
env:
|
||||
GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_xxxxxxxxxxxxxxxxxxxx"
|
||||
|
||||
company_api:
|
||||
url: "https://mcp.internal.company.com/mcp"
|
||||
headers:
|
||||
Authorization: "Bearer sk-xxxxxxxxxxxxxxxxxxxx"
|
||||
timeout: 300
|
||||
```
|
||||
|
||||
All tools from all servers are registered and available simultaneously. Each server's tools are prefixed with its name to avoid collisions.
|
||||
|
||||
## Sampling (Server-Initiated LLM Requests)
|
||||
|
||||
Hermes supports MCP's `sampling/createMessage` capability — MCP servers can request LLM completions through the agent during tool execution. This enables agent-in-the-loop workflows (data analysis, content generation, decision-making).
|
||||
|
||||
Sampling is **enabled by default**. Configure per server:
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
my_server:
|
||||
command: "npx"
|
||||
args: ["-y", "my-mcp-server"]
|
||||
sampling:
|
||||
enabled: true # default: true
|
||||
model: "gemini-3-flash" # model override (optional)
|
||||
max_tokens_cap: 4096 # max tokens per request
|
||||
timeout: 30 # LLM call timeout (seconds)
|
||||
max_rpm: 10 # max requests per minute
|
||||
allowed_models: [] # model whitelist (empty = all)
|
||||
max_tool_rounds: 5 # tool loop limit (0 = disable)
|
||||
log_level: "info" # audit verbosity
|
||||
```
|
||||
|
||||
Servers can also include `tools` in sampling requests for multi-turn tool-augmented workflows. The `max_tool_rounds` config prevents infinite tool loops. Per-server audit metrics (requests, errors, tokens, tool use count) are tracked via `get_mcp_status()`.
|
||||
|
||||
Disable sampling for untrusted servers with `sampling: { enabled: false }`.
|
||||
|
||||
## Notes
|
||||
|
||||
- MCP tools are called synchronously from the agent's perspective but run asynchronously on a dedicated background event loop
|
||||
- Tool results are returned as JSON with either `{"result": "..."}` or `{"error": "..."}`
|
||||
- The native MCP client is independent of `mcporter` -- you can use both simultaneously
|
||||
- Server connections are persistent and shared across all conversations in the same agent process
|
||||
- Adding or removing servers requires restarting the agent (no hot-reload currently)
|
||||
@@ -0,0 +1,75 @@
|
||||
# Petdex — Animated Pet Mascots
|
||||
|
||||
Browse, install, and select animated "pet" mascots from the public
|
||||
[petdex](https://github.com/crafter-station/petdex) gallery. An installed pet
|
||||
reacts to agent activity (idle, running a tool, reviewing, error, done) across
|
||||
the Hermes CLI, TUI, and desktop app. This skill drives the `hermes pets` CLI
|
||||
and the `display.pet` config — it does not generate sprites.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user wants a desktop/terminal mascot or asks about "pets" / petdex.
|
||||
- The user wants to change, preview, or disable the active pet.
|
||||
- Diagnosing why a pet isn't showing (terminal graphics support, config).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Network access to `petdex.dev` for the gallery/manifest (read-only, no auth).
|
||||
- Pillow (a core Hermes dependency) for sprite decoding — already installed.
|
||||
- For full-fidelity terminal rendering: a graphics-capable terminal (kitty,
|
||||
Ghostty, WezTerm, iTerm2, or sixel). Otherwise a truecolor Unicode
|
||||
half-block fallback is used automatically.
|
||||
|
||||
## How to Run
|
||||
|
||||
Use the `terminal` tool to run `hermes pets <subcommand>`.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Goal | Command |
|
||||
| --- | --- |
|
||||
| Browse the gallery | `hermes pets list` (add a substring to filter: `hermes pets list cat`) |
|
||||
| List installed pets | `hermes pets list --installed` |
|
||||
| Install a pet | `hermes pets install <slug>` (add `--select` to make it active) |
|
||||
| Set the active pet | `hermes pets select <slug>` (omit slug for a picker) |
|
||||
| Resize the pet everywhere | `hermes pets scale <factor>` (e.g. `0.5`, clamped 0.1–3.0) |
|
||||
| Preview/animate in terminal | `hermes pets show [slug] [--cycle] [--state run]` |
|
||||
| Disable the pet | `hermes pets off` |
|
||||
| Remove a pet | `hermes pets remove <slug>` |
|
||||
| Diagnose setup | `hermes pets doctor` |
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Find a pet: `hermes pets list <query>` and note its `slug`.
|
||||
2. Install + activate: `hermes pets install <slug> --select`.
|
||||
3. Preview it: `hermes pets show` (Ctrl+C to stop).
|
||||
4. Confirm setup: `hermes pets doctor` — shows the resolved pet, configured
|
||||
render mode, detected terminal graphics protocol, and effective mode.
|
||||
|
||||
Pets install into `<HERMES_HOME>/pets/<slug>/` (profile-aware). Selecting a pet
|
||||
writes `display.pet.slug` + `display.pet.enabled` to `config.yaml`.
|
||||
|
||||
## Configuration
|
||||
|
||||
Under `display.pet` in `config.yaml`:
|
||||
|
||||
- `enabled` (bool) — master on/off.
|
||||
- `slug` (str) — active pet; empty = first installed.
|
||||
- `render_mode` — `auto` (detect) | `kitty` | `iterm` | `sixel` | `unicode` | `off`.
|
||||
- `scale` (float) — on-screen size of the native 192×208 frames (default 0.33,
|
||||
clamped 0.1–3.0). One knob resizes every surface; set it with
|
||||
`hermes pets scale <factor>`, the `/pet scale` slash command, or the desktop
|
||||
Appearance slider.
|
||||
- `unicode_cols` (int) — width in columns for the Unicode fallback.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- A pet only shows once one is installed AND selected (`enabled: true`).
|
||||
- Inside a pipe/redirect (no TTY) terminal rendering is disabled by design.
|
||||
- The petdex npm CLI installs to `~/.codex/pets`; Hermes uses its own
|
||||
profile-scoped `<HERMES_HOME>/pets/` instead — install through `hermes pets`.
|
||||
|
||||
## Verification
|
||||
|
||||
- `hermes pets doctor` reports `✓ ready` when a pet is installed, selected,
|
||||
enabled, and Pillow is importable.
|
||||
@@ -0,0 +1,128 @@
|
||||
# Nous Portal — authenticating third-party apps against the subscription
|
||||
|
||||
Recurring user question: "Can app X (Karakeep, OpenWebUI, LibreChat, OpenViking,
|
||||
LangChain pipeline, n8n flow, etc.) use my Nous Portal subscription without me
|
||||
copy-pasting an API key — ideally via the Portal login I already have?"
|
||||
|
||||
The honest answer has three architectural layers people conflate. Walk through
|
||||
them in order before proposing solutions.
|
||||
|
||||
---
|
||||
|
||||
## Layer 1 — Is this thing a Hermes plugin, or a separate app?
|
||||
|
||||
This is the question to answer FIRST. The "OpenViking" case in particular
|
||||
trips agents up.
|
||||
|
||||
| Surface | What it actually is | Auth path |
|
||||
|---|---|---|
|
||||
| **OpenViking memory plugin** (`plugins/memory/openviking/`) | Code that runs **inside the Hermes process**. Its LLM calls go through Hermes's already-configured provider. | Already uses Portal if user's Hermes is configured for Portal. Nothing extra needed. `OPENVIKING_API_KEY` is the OpenViking *server's* own auth, not LLM auth. |
|
||||
| **OpenViking the standalone server** (separate container) | A separate context-DB service. If it ever calls an LLM on its own, that's a separate HTTP client. | Same as any external app — Layer 2/3 below. |
|
||||
| **Karakeep, n8n, LibreChat, OpenWebUI, any self-hosted app** | Different process, often different machine. Makes its own HTTPS calls to `inference-api.nousresearch.com`. | Layer 2/3 below. |
|
||||
|
||||
**Pitfall to avoid**: do not pitch "OAuth into Portal" as the solution for a
|
||||
plugin that already runs inside Hermes. That LLM call is already authenticated
|
||||
via Hermes's provider config. The plugin's own server auth (e.g.
|
||||
`OPENVIKING_API_KEY` for talking to the OpenViking REST API) is unrelated to
|
||||
Portal.
|
||||
|
||||
---
|
||||
|
||||
## Layer 2 — For genuinely external apps, what does Portal actually expose?
|
||||
|
||||
Portal at `https://inference-api.nousresearch.com/v1` is an OpenAI-compatible
|
||||
inference endpoint. It accepts **bearer-token authentication only**: either
|
||||
|
||||
1. **A static API key** from `portal.nousresearch.com → API Keys`, or
|
||||
2. **An x402-protocol payment header** (Solana USDC, beta, anonymous, per-request).
|
||||
|
||||
There is **no general OAuth 2.0 authorization server**. There is no
|
||||
"Sign in with Nous Portal" SSO that third-party apps can register as clients
|
||||
against. There is no shared cookie or session that browser-Portal-login
|
||||
extends to other apps on the same machine.
|
||||
|
||||
What Hermes Agent has that *feels* like OAuth — `hermes login --provider nous`
|
||||
opening a browser, user signs in, token lands in `~/.hermes/auth.json` — is a
|
||||
**Hermes-specific browser flow**. Under the hood it produces a credential
|
||||
Hermes uses as a bearer. It is not a public OAuth provider that Karakeep et al.
|
||||
can implement a client for, because it isn't an OAuth provider at all from the
|
||||
outside.
|
||||
|
||||
---
|
||||
|
||||
## Layer 3 — Can we bridge the gap without Portal changing anything?
|
||||
|
||||
Yes. The pattern is a **local credential-broker proxy**. Even without a public
|
||||
OAuth flow, an app on the user's machine can:
|
||||
|
||||
1. Read Hermes's existing Portal credential out of `~/.hermes/auth.json`.
|
||||
2. Expose a local OpenAI-compatible endpoint at `http://localhost:NNNN/v1`.
|
||||
3. Forward incoming requests to `inference-api.nousresearch.com/v1` with that
|
||||
bearer attached.
|
||||
|
||||
Karakeep/OpenWebUI/etc. then point at `http://localhost:NNNN/v1` with any
|
||||
placeholder key. The user never copies their Portal key around — the proxy
|
||||
rides on the credential Hermes already holds.
|
||||
|
||||
Where this could live in Hermes:
|
||||
|
||||
- `gateway/platforms/api_server.py` is the precedent — it exposes the agent
|
||||
over a local OpenAI-compatible endpoint, but routes through the full agent
|
||||
loop (tool calls and all). The proxy variant is **pure inference
|
||||
pass-through**: no agent loop, no tools, just forward `/chat/completions`
|
||||
upstream with the user's stored Portal bearer.
|
||||
- ~150 lines as a new gateway adapter or a plugin under `plugins/`.
|
||||
- Token refresh: if the browser-OAuth flow produces a refreshable token, the
|
||||
credential pool's refresh logic already exists. If it's a long-lived static
|
||||
bearer, even simpler.
|
||||
|
||||
This is genuinely useful and worth shipping — it's the answer to "use my
|
||||
Portal sub with $external_app without copy-pasting keys."
|
||||
|
||||
---
|
||||
|
||||
## Real OAuth provider on Portal — when is it worth pitching?
|
||||
|
||||
Only when the consumer is *another first-party Nous thing* (a future SDK, a
|
||||
Nous-branded extension, a Discord-bot integration that needs per-user
|
||||
delegation, etc.). Pitching it as the answer to "use my Portal sub with
|
||||
Karakeep" is selling the user a thing that won't reach them: even if Portal
|
||||
shipped OAuth tomorrow, Karakeep's LLM-provider config UI is `base_url +
|
||||
bearer_token` with no OAuth client, no callback handler, no token refresh.
|
||||
The OpenAI ecosystem standardized on static bearers and downstream apps
|
||||
won't rebuild their config UX to accommodate a new auth flow.
|
||||
|
||||
The features that would actually help users today, and that Portal could ship
|
||||
without depending on third-party app changes:
|
||||
|
||||
- **Scoped, named, revocable API keys** with last-used timestamps. Same UX
|
||||
benefits people want from OAuth (revoke a compromised key, see what's using
|
||||
the sub, scope a key to specific models), in a shape every existing app
|
||||
already supports.
|
||||
- **Per-key rate limits** so a noisy app can be capped without eating the
|
||||
user's headroom for Hermes itself.
|
||||
|
||||
---
|
||||
|
||||
## Talking-points cheatsheet (for next time)
|
||||
|
||||
When the user asks "can $APP use my Portal subscription":
|
||||
|
||||
1. First decide: Hermes plugin (runs inside Hermes) or separate app? If plugin,
|
||||
it already uses Portal via Hermes's provider config — done.
|
||||
2. If separate app: today, paste the static API key from Portal → API Keys.
|
||||
Base URL `https://inference-api.nousresearch.com/v1`. Rate limits are
|
||||
subscription-tier based, applied per-key.
|
||||
3. If the user pushes back with "but I don't want to paste a key" — that's
|
||||
the local-broker-proxy answer (Layer 3). Worth building. Not a Portal-side
|
||||
OAuth roadmap problem.
|
||||
4. Mixed setup ("Portal for some things, OpenRouter/Ollama Cloud for the
|
||||
Hermes agent itself") is fully supported. Hermes treats agent
|
||||
provider/model and tool-side LLM calls as independent config; you can
|
||||
point each at a different endpoint.
|
||||
|
||||
**Note on the Tool Gateway**: the "no separate accounts, no API key juggling"
|
||||
pitch in the Tool Gateway announcement is specifically about Hermes Agent's
|
||||
*tools* (web search, browser, image gen, TTS) flowing through the Portal
|
||||
subscription when Hermes is configured to use Portal as its provider. It is
|
||||
**not** a claim that arbitrary third-party apps inherit Portal auth.
|
||||
@@ -0,0 +1,48 @@
|
||||
# Project Context Files
|
||||
|
||||
Hermes injects project-level instructions into the system prompt by reading context files from the working directory. The discovery order is **first match wins** — only one project context source is loaded per session.
|
||||
|
||||
| File (in priority order) | Discovery | Use when |
|
||||
|---|---|---|
|
||||
| `.hermes.md` / `HERMES.md` | Walks parents up to the git root, stops at git root | You want hierarchical project rules (root + per-package overrides) |
|
||||
| `AGENTS.md` / `agents.md` | **Cwd only** — subdirectory and parent copies are ignored | You want portable agent instructions that work the same in Hermes, Claude Code, Codex, etc. |
|
||||
| `CLAUDE.md` / `claude.md` | Cwd only | Same as AGENTS.md, Claude-flavored |
|
||||
| `.cursorrules` / `.cursor/rules/*.mdc` | Cwd only | Migrating from Cursor |
|
||||
|
||||
`SOUL.md` (in `$HERMES_HOME`) is independent and always loaded when present — it sets the agent's identity, not project rules.
|
||||
|
||||
### Pick the right one
|
||||
|
||||
- **Use `.hermes.md`** when you want Hermes-specific behavior that lives above the cwd (root + subtree), or when you want rules to inherit from a parent directory. The parent walk stops at the git root, so a home-level `.hermes.md` won't leak into every project (a git repo's root is the boundary).
|
||||
- **Use `AGENTS.md`** when the same project will also be worked on by other agents (Codex, Claude Code, OpenCode). Those tools all have their own conventions for `AGENTS.md`, and the "cwd only" contract keeps the file portable.
|
||||
- **Don't put project rules in `~/.hermes/AGENTS.md`** (or any other home-level location). When Hermes runs with that directory as cwd, the file loads — but only for that one directory. For cross-project context, use `SOUL.md` (in `$HERMES_HOME`, identity-only) or install a skill via `hermes skills install`.
|
||||
|
||||
### Size and truncation
|
||||
|
||||
Each context file is capped at 20,000 characters. Files longer than that get **head + tail** truncated (the middle is dropped, with a `[...truncated...]` marker). For large project rules, prefer splitting into multiple skills over cramming one file.
|
||||
|
||||
### Security
|
||||
|
||||
All context files pass through the threat-pattern scanner before reaching the system prompt. Patterns matching prompt injection or promptware are replaced with a `[BLOCKED: ...]` placeholder. This means an `AGENTS.md` containing obvious injection attempts won't reach the model — the scanner blocks the content, not the file, so the rest of the file still loads.
|
||||
|
||||
### Disable for one session
|
||||
|
||||
`hermes --ignore-rules` skips auto-injection of all project context files (`.hermes.md`, `AGENTS.md`, `CLAUDE.md`, `.cursorrules`) **and** `SOUL.md` identity, plus user config, plugins, and MCP servers. Use it to isolate whether a problem is your setup or Hermes itself.
|
||||
|
||||
### Example: a small `.hermes.md`
|
||||
|
||||
```markdown
|
||||
# My Project
|
||||
|
||||
Hermes: when working in this repo, follow these rules.
|
||||
|
||||
## Build
|
||||
- Always run `make test` before declaring a change done.
|
||||
- Use `uv run` for Python, not `pip install`.
|
||||
|
||||
## Style
|
||||
- Prefer `pathlib.Path` over `os.path`.
|
||||
- No `print()` in production code — use the `logger`.
|
||||
```
|
||||
|
||||
That file at `/home/me/projects/myrepo/.hermes.md` is auto-loaded when Hermes runs in any subdirectory of `/home/me/projects/myrepo`, but not when it runs in `/home/me/other-project`.
|
||||
@@ -0,0 +1,64 @@
|
||||
# Providers & Model Aliases
|
||||
|
||||
Set via `hermes model` (picker) or `hermes setup`. 35+ provider profiles ship as
|
||||
plugins under `plugins/model-providers/`; user plugins of the same name override.
|
||||
Full docs: https://hermes-agent.nousresearch.com/docs/integrations/providers
|
||||
|
||||
### Providers
|
||||
|
||||
| Provider | Auth | Key env var(s) |
|
||||
|----------|------|----------------|
|
||||
| openrouter | API key | `OPENROUTER_API_KEY` |
|
||||
| anthropic | API key | `ANTHROPIC_API_KEY` (also `CLAUDE_CODE_OAUTH_TOKEN`) |
|
||||
| nous | OAuth device code | `hermes auth add nous` (or `NOUS_API_KEY`) |
|
||||
| openai-codex | OAuth | `hermes auth add openai-codex` |
|
||||
| qwen-oauth | OAuth | `hermes auth add qwen-oauth` |
|
||||
| minimax-oauth | OAuth | `hermes auth add minimax-oauth` |
|
||||
| copilot | Token | `COPILOT_GITHUB_TOKEN` / `GH_TOKEN` (Copilot device flow — `gh auth login` tokens do NOT work) |
|
||||
| copilot-acp | External CLI | Copilot CLI on PATH or `COPILOT_CLI_PATH` |
|
||||
| gemini | API key | `GOOGLE_API_KEY` or `GEMINI_API_KEY` |
|
||||
| xai | API key | `XAI_API_KEY` (SuperGrok OAuth also supported) |
|
||||
| deepseek | API key | `DEEPSEEK_API_KEY` |
|
||||
| zai (GLM) | API key | `GLM_API_KEY` / `ZAI_API_KEY` |
|
||||
| minimax / minimax-cn | API key | `MINIMAX_API_KEY` / `MINIMAX_CN_API_KEY` |
|
||||
| kimi-coding / -cn | API key | `KIMI_API_KEY` / `KIMI_CN_API_KEY` |
|
||||
| alibaba (+coding-plan) | API key | `DASHSCOPE_API_KEY` / `ALIBABA_CODING_PLAN_API_KEY` |
|
||||
| xiaomi | API key | `XIAOMI_API_KEY` |
|
||||
| huggingface | Token | `HF_TOKEN` |
|
||||
| fireworks / novita / nvidia / deepinfra / gmi / arcee / stepfun / upstage / kilocode / ai-gateway / opencode-zen / opencode-go / ollama-cloud | API key | `<NAME>_API_KEY` |
|
||||
| bedrock / vertex / azure-foundry | Cloud SDK / key | AWS SDK creds / Vertex ADC / `AZURE_FOUNDRY_API_KEY` |
|
||||
| custom | Config | `model.base_url` + `model.api_key` in config.yaml |
|
||||
|
||||
Multiple credentials per provider pool and rotate automatically (`hermes auth`).
|
||||
Fallback chain when the primary fails: `hermes fallback add|remove|list`.
|
||||
|
||||
### User-defined model aliases
|
||||
|
||||
Work with `/model <name>` in CLI and every gateway platform. Resolved by
|
||||
`hermes_cli/model_switch.py::resolve_alias()`; user aliases are checked BEFORE
|
||||
the built-in table, so a user `sonnet`/`grok` shadows the built-in.
|
||||
|
||||
```yaml
|
||||
# Full form
|
||||
model_aliases:
|
||||
fav:
|
||||
model: claude-sonnet-4.6
|
||||
provider: anthropic
|
||||
local-qwen:
|
||||
model: qwen3.5:397b
|
||||
provider: custom
|
||||
base_url: "https://ollama.com/v1"
|
||||
|
||||
# Short form ("provider/model"), also via CLI:
|
||||
# hermes config set model.aliases.fav openrouter/anthropic/claude-sonnet-4.6
|
||||
model:
|
||||
aliases:
|
||||
fav: openrouter/anthropic/claude-sonnet-4.6
|
||||
```
|
||||
|
||||
`/model fav` — session-scoped; add `--global` to persist as default.
|
||||
|
||||
Built-in aliases (catalog-resolved against the active provider): `sonnet`,
|
||||
`opus`, `haiku`, `claude`, `gpt5`, `gpt`, `codex`, `o3`, `o4`, `gemini`,
|
||||
`deepseek`, `grok`, `llama`, `qwen`, `minimax`, `nemotron`, `kimi`, `glm`,
|
||||
`step`, `mimo`, `trinity`.
|
||||
@@ -0,0 +1,67 @@
|
||||
# Security & Privacy Toggles
|
||||
|
||||
Common "why is Hermes doing X to my output / tool calls / commands?" toggles — and the exact commands to change them. Most of these need a fresh session (`/reset` in chat, or start a new `hermes` invocation) because they're read once at startup.
|
||||
|
||||
### Secret redaction in tool output
|
||||
|
||||
Secret redaction is **on by default** — tool output (terminal stdout, `read_file`, web content, subagent summaries, etc.) is scanned for strings that look like API keys, tokens, and secrets before it enters the conversation context and logs. Leave it enabled for normal use:
|
||||
|
||||
```bash
|
||||
hermes config set security.redact_secrets true # keep enabled globally
|
||||
```
|
||||
|
||||
**Restart required.** `security.redact_secrets` is snapshotted at import time — toggling it mid-session (e.g. via `export HERMES_REDACT_SECRETS=false` from a tool call) will NOT take effect for the running process. Tell the user to change it in config from a terminal, then start a new session. This is deliberate — it prevents an LLM from flipping the toggle on itself mid-task.
|
||||
|
||||
Disable only when you deliberately need raw credential-like strings for debugging or redactor development:
|
||||
```bash
|
||||
hermes config set security.redact_secrets false
|
||||
```
|
||||
|
||||
### PII redaction in gateway messages
|
||||
|
||||
Separate from secret redaction. When enabled, the gateway hashes user IDs and strips phone numbers from the session context before it reaches the model:
|
||||
|
||||
```bash
|
||||
hermes config set privacy.redact_pii true # enable
|
||||
hermes config set privacy.redact_pii false # disable (default)
|
||||
```
|
||||
|
||||
### Command approval prompts
|
||||
|
||||
By default (`approvals.mode: smart`), Hermes asks an auxiliary LLM to assess shell commands flagged as destructive (`rm -rf`, `git reset --hard`, etc.). The modes are:
|
||||
|
||||
- `smart` — auto-approve a low-risk command once, deny high-risk commands, and prompt when uncertain (default)
|
||||
- `manual` — always prompt
|
||||
- `off` — skip all approval prompts (equivalent to `--yolo`)
|
||||
|
||||
```bash
|
||||
hermes config set approvals.mode smart # recommended middle ground
|
||||
hermes config set approvals.mode off # bypass everything (not recommended)
|
||||
```
|
||||
|
||||
Per-invocation bypass without changing config:
|
||||
- `hermes --yolo …`
|
||||
- `export HERMES_YOLO_MODE=1`
|
||||
|
||||
Note: YOLO / `approvals.mode: off` does NOT turn off secret redaction. They are independent.
|
||||
|
||||
### "Reset permissions" / "make Hermes ask again"
|
||||
|
||||
The user usually means: wipe the accumulated "Always allow" state — NOT yolo
|
||||
mode, and NOT a per-edit diff prompt (which doesn't exist; file writes never
|
||||
go through the approval prompt, only shell commands do). Two stores hold it:
|
||||
|
||||
1. Shell-command allowlist: `hermes config set command_allowlist '[]'`
|
||||
2. Shell-hook consent (only if present): `rm -f ~/.hermes/shell-hooks-allowlist.json`
|
||||
|
||||
Then sanity-check `hermes config get approvals.mode` (should not be `off`)
|
||||
and confirm `--yolo` isn't baked into their launch alias or systemd unit.
|
||||
|
||||
### Shell hooks allowlist
|
||||
|
||||
Some shell-hook integrations require explicit allowlisting before they fire. Managed via `~/.hermes/shell-hooks-allowlist.json` — prompted interactively the first time a hook wants to run.
|
||||
|
||||
### Disabling the web/browser/image-gen tools
|
||||
|
||||
To keep the model away from network or media tools entirely, open `hermes tools` and toggle per-platform. Takes effect on next session (`/reset`). See `references/configuration.md` for the toolset list.
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
# Slash Commands (In-Session)
|
||||
|
||||
Registry of record: `hermes_cli/commands.py` (`COMMAND_REGISTRY`) — every
|
||||
consumer (autocomplete, `/help`, Telegram menu, Slack mapping) derives from
|
||||
it. New commands land often; `/help` in-session is always authoritative.
|
||||
(CLI) = interactive CLI/TUI only. (GW) = gateway platforms only.
|
||||
|
||||
### Session
|
||||
```
|
||||
/new (/reset) [name] Fresh session
|
||||
/clear Clear screen + new session (CLI)
|
||||
/retry Resend last message
|
||||
/undo [N] Back up N user turns and re-prompt
|
||||
/title [name] Name the session
|
||||
/prompt (/compose) Compose next prompt in $EDITOR (CLI)
|
||||
/compress (/compact) Compress context ('here [N]' keeps N turns; --preview)
|
||||
/stop Kill background processes
|
||||
/rollback [N] List/restore filesystem checkpoints
|
||||
/diff [mode] [--stat] Git changes in cwd (staged|all|session modes)
|
||||
/snapshot [sub] Create/restore Hermes config+state snapshots (CLI)
|
||||
/background (/bg) <p> Run prompt in background
|
||||
/queue (/q) <prompt> Queue prompt for next turn
|
||||
/steer <prompt> Inject a message after the next tool call
|
||||
/agents (/tasks) Show active agents and running tasks
|
||||
/goal [text|sub] Standing goal across turns (status|pause|resume|clear)
|
||||
/subgoal [text] Add/manage criteria on the active goal
|
||||
/branch (/fork) [name] Branch the session
|
||||
/resume [name] Resume a named session
|
||||
/sessions Browse and resume previous sessions
|
||||
/handoff <platform> Hand live session off to a messaging platform (CLI)
|
||||
/status Session, model, token, and context info
|
||||
/redraw Force full UI repaint (CLI)
|
||||
```
|
||||
|
||||
### Configuration
|
||||
```
|
||||
/config Show config (CLI)
|
||||
/model [name] [--global] Switch model (session-scoped by default)
|
||||
/personality [name] Set a personality
|
||||
/reasoning [level|show|hide] Reasoning effort/display (none..xhigh|max|ultra)
|
||||
/fast [normal|fast] Priority/fast processing tier
|
||||
/verbose Cycle tool progress: off → new → all → verbose → log (CLI)
|
||||
/voice [on|off|tts] Voice mode
|
||||
/yolo Toggle approval bypass
|
||||
/busy [queue|steer|interrupt] What Enter does while working (CLI)
|
||||
/indicator [style] TUI busy indicator: kaomoji|emoji|unicode|ascii (CLI)
|
||||
/footer [on|off] Gateway runtime-metadata footer on replies
|
||||
/skin [name] Change theme (CLI)
|
||||
/statusbar (/sb) Toggle status bar (CLI)
|
||||
/battery [on|off] Battery indicator in status bar (CLI)
|
||||
/timestamps (/ts) [on|off] Message timestamps (CLI)
|
||||
/codex-runtime [auto|codex_app_server] Codex runtime toggle
|
||||
```
|
||||
|
||||
### Tools & Skills
|
||||
```
|
||||
/tools [list|enable|disable] Manage tools (CLI)
|
||||
/toolsets List toolsets (CLI)
|
||||
/skills Search/install/manage skills (CLI)
|
||||
/bundles List skill bundles (/<name> loads several skills)
|
||||
/learn <source> Learn a reusable skill from dirs/URLs/this chat
|
||||
/memory [pending|approve|reject] Review pending memory writes / approval gate
|
||||
/pet [toggle|list|<slug>] Petdex mascot control (CLI)
|
||||
/hatch [description] Generate a new pet from a description (CLI)
|
||||
/cron [sub] Manage scheduled tasks (CLI)
|
||||
/suggestions (/suggest) Review suggested automations
|
||||
/blueprint (/bp) [name] Set up an automation from a blueprint
|
||||
/curator [sub] Skill maintenance (status, run, pin, archive, …)
|
||||
/kanban [sub] Multi-profile collaboration board
|
||||
/moa <prompt> One prompt through the Mixture-of-Agents preset
|
||||
/reload Reload .env into the running session (CLI)
|
||||
/reload-mcp Reload MCP servers
|
||||
/reload-skills Re-scan skills directory
|
||||
/browser [connect|status] CDP connection to your live browser (CLI)
|
||||
/plugins List plugins (CLI)
|
||||
```
|
||||
|
||||
### Gateway
|
||||
```
|
||||
/approve [session|always] Approve a pending dangerous command (GW)
|
||||
/deny [all] [reason] Deny a pending dangerous command (GW)
|
||||
/restart Restart gateway after draining active runs (GW)
|
||||
/sethome Set current chat as home channel (GW)
|
||||
/topic [off|help] Telegram DM topic sessions (GW)
|
||||
/platform <pause|resume|list> Pause/resume a failing platform (GW)
|
||||
/commands [page] Browse all commands, paginated (GW)
|
||||
```
|
||||
|
||||
### Info
|
||||
```
|
||||
/help Show commands
|
||||
/usage [reset] Token usage and rate limits
|
||||
/insights [days] Usage analytics
|
||||
/whoami Slash-command access level (admin/user)
|
||||
/profile Active profile info
|
||||
/platforms (/gateway) Platform connection status (CLI)
|
||||
/journey (/learning) Learned skills + memories timeline (CLI)
|
||||
/subscription (/upgrade) Nous plan info (CLI)
|
||||
/topup Nous balance / billing
|
||||
/copy [N] Copy last response to clipboard (CLI)
|
||||
/paste Attach clipboard image (CLI)
|
||||
/image <path> Attach a local image file (CLI)
|
||||
/update Update Hermes to latest
|
||||
/version (/v) Show version
|
||||
/debug [nous|local] Upload debug report, get shareable links
|
||||
```
|
||||
|
||||
### Exit
|
||||
```
|
||||
/quit (/exit) [--delete] Exit CLI; --delete also removes session history
|
||||
```
|
||||
@@ -0,0 +1,127 @@
|
||||
# Themes / Skins — Author a Hermes Color Theme
|
||||
|
||||
Author a Hermes **skin** — one YAML file that themes the CLI, the TUI, and the
|
||||
desktop GUI at once. The skin engine (`hermes_cli/skin_engine.py`) resolves the
|
||||
active skin and the gateway pushes it to every surface, so a file dropped in
|
||||
`~/.hermes/skins/` is the theme analogue of a plugin: no code, all surfaces. This
|
||||
skill covers writing a good skin and activating it; it does not build GUI theme
|
||||
editors or ship built-in presets.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user asks for a custom look ("make me a synthwave theme", "dark forest
|
||||
vibes", "match my brand colors") for Hermes itself.
|
||||
- The user wants the CLI/TUI/desktop to share one coordinated palette.
|
||||
- The user wants to iterate live ("that coral is too loud, make it teal") — edit
|
||||
the active skin's YAML and every surface repaints as your tool finishes.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Write access to the Hermes home dir — `~/.hermes` by default, or `$HERMES_HOME`
|
||||
/ the active profile's dir. Skins live in `<hermes-home>/skins/`.
|
||||
- Native tools: `write_file` (create the YAML), `read_file` / `search_files`
|
||||
(inspect existing skins), `terminal` (activate via `hermes config set`).
|
||||
|
||||
## How to Run
|
||||
|
||||
1. Pick a lowercase, hyphen-safe `name` (e.g. `synthwave`).
|
||||
2. Copy `templates/skin.yaml` and fill in the palette (keep every key — missing
|
||||
keys inherit the `default` skin).
|
||||
3. `write_file` it to `<hermes-home>/skins/<name>.yaml`.
|
||||
4. Activate it (see Procedure). Confirm the change landed.
|
||||
|
||||
## Quick Reference — element → key
|
||||
|
||||
Hex (`#rrggbb`). Theming is **semantic**: one key colors every element that plays
|
||||
that role, so match the element to its key. To recolor a specific element, set the
|
||||
key in its row (element-specific keys fall back to the shared one when unset).
|
||||
|
||||
| Visible element | Key to set | Falls back to |
|
||||
|---|---|---|
|
||||
| App background (whole TUI + GUI) | `background` | terminal default |
|
||||
| **Tool-call marker** (`●`, tool spinner) | `ui_tool` | `ui_accent` |
|
||||
| **Thinking / reasoning text** | `ui_thinking` | `banner_dim` |
|
||||
| Accent — headings, links, chevrons, `Σ` | `ui_accent` / `banner_accent` | — |
|
||||
| Heading / primary text | `banner_title` / `ui_primary` | — |
|
||||
| Body / label text, user messages | `ui_text` / `banner_text`, `ui_label` | — |
|
||||
| Muted / secondary, tree connectors | `banner_dim` | — |
|
||||
| Borders, rules, gutters | `ui_border` / `banner_border` | — |
|
||||
| Prompt symbol color | `prompt` | `banner_text` |
|
||||
| Success / warn / error | `ui_ok` / `ui_warn` / `ui_error` | — |
|
||||
| Status bar text + usage | `status_bar_text`, `status_bar_good/warn/bad/critical` | — |
|
||||
| Diff add/remove (line + word) | `diff_added` / `diff_removed` / `diff_added_word` / `diff_removed_word` | built-in |
|
||||
| Code syntax (string/number/keyword/comment) | `syntax_string` / `syntax_number` / `syntax_keyword` / `syntax_comment` | accent/text/border/muted |
|
||||
| Completion menu | `completion_menu_bg` / `completion_menu_current_bg` / `…_meta_bg` | — |
|
||||
|
||||
Note the sharing: `ui_accent` colors tool markers **and** headings/links/chevrons,
|
||||
so to recolor *only* tool calls (the classic "change the gold `●`") set `ui_tool`.
|
||||
`branding` (`agent_name`, `prompt_symbol`, `welcome`, `goodbye`, `help_header`),
|
||||
`spinner`, and `tool_prefix` are optional flavor; full schema in
|
||||
`hermes_cli/skin_engine.py`.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. **Design the palette.** Choose a `background` first, then an `ui_accent` that
|
||||
clears WCAG AA against it (~4.5:1) so labels stay legible — the GUI enforces
|
||||
contrast but a low-contrast accent still looks washed out. Keep
|
||||
`ui_ok`/`ui_warn`/`ui_error` recognizably green/amber/red.
|
||||
2. **Write the file** to `<hermes-home>/skins/<name>.yaml`. Every top-level
|
||||
`colors` key from the template should be present.
|
||||
3. **Apply it yourself — never hand-edit `config.yaml`.** Run the safe writer via
|
||||
`terminal`:
|
||||
```
|
||||
hermes config set display.skin <name>
|
||||
```
|
||||
The gateway's skin watcher notices the change and **repaints every surface live
|
||||
within ~a second** — CLI, TUI, and desktop — and the skin appears in
|
||||
Appearance / `Cmd-K` / `/skin`. You apply it; do NOT tell the user to run
|
||||
`/skin` (they still can, but it's your job). The writer emits valid YAML — a
|
||||
hand-edit can corrupt the file and break the live gateway (including `/`).
|
||||
4. **Confirm the new look landed** and tell the user how to revert: run
|
||||
`hermes config set display.skin default` (or they can `/skin default`).
|
||||
|
||||
## Tweak the active look (change one thing)
|
||||
|
||||
When the user wants to adjust the CURRENT look ("make the tool `●` cyan", "warmer
|
||||
background"), use the one deterministic command — it edits the ACTIVE skin's ONE
|
||||
key in place, so everything else (background included) is untouched:
|
||||
|
||||
```
|
||||
hermes skin set <key> <hex> # e.g. hermes skin set ui_tool "#00FFFF"
|
||||
```
|
||||
|
||||
It edits the active skin's file (a built-in is forked into an editable copy that
|
||||
keeps its full palette), the watcher repaints live, and nothing else moves. Do
|
||||
NOT hand-write a new skin from `default` for a tweak — that drops the current
|
||||
palette and resets the background. `hermes skin set background "#08201f"` changes
|
||||
only the background; `hermes skin use <name>` / `hermes skin list` switch and
|
||||
enumerate.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- **Don't hardcode `~/.hermes`** when a profile is active — resolve the real home
|
||||
from `$HERMES_HOME` first, falling back to `~/.hermes`.
|
||||
- **Keep `#rrggbb` hex.** Shorthand `#rgb`, `rgb()`, and named colors are not
|
||||
guaranteed to parse on every surface.
|
||||
- **Set `background`.** Without it the GUI has to guess a base surface from text
|
||||
luminance — usable, but you lose control of the app background.
|
||||
- **Name collisions**: a skin named like a desktop built-in (`mono`, `slate`,
|
||||
`cyberpunk`, `nous`, `midnight`, `ember`) won't override that built-in on the
|
||||
GUI. Pick a fresh name.
|
||||
- **Never hand-edit `config.yaml` to activate.** Use `hermes config set
|
||||
display.skin <name>` — a stray indent in a manual edit corrupts the file and
|
||||
can break the live gateway (including `/`). One command, always valid.
|
||||
- **You apply it, not the user.** `hermes config set display.skin <name>` is
|
||||
enough — the gateway's watcher repaints every surface within ~a second. Don't
|
||||
defer to "type /skin yourself"; that's the old behavior.
|
||||
- **To change one color, edit the ACTIVE skin — never fork `default`.** Forking
|
||||
`default` for a tweak drops the current palette: a skin with no `background`
|
||||
resets the terminal to its own default (often black). Patch the active skin's
|
||||
file in place so `background` and everything else survive.
|
||||
|
||||
## Verification
|
||||
|
||||
- `read_file` the written `<hermes-home>/skins/<name>.yaml` and confirm valid
|
||||
YAML with the intended `name` and `colors`.
|
||||
- Run `hermes config get display.skin` and confirm it reports `<name>`.
|
||||
- The repaint lands as this turn ends — ask the user to confirm the new look.
|
||||
@@ -0,0 +1,54 @@
|
||||
# Troubleshooting
|
||||
|
||||
### Voice not working
|
||||
1. Check `stt.enabled: true` in config.yaml
|
||||
2. Verify provider: `pip install faster-whisper` or set API key
|
||||
3. In gateway: `/restart`. In CLI: exit and relaunch.
|
||||
|
||||
### Tool not available
|
||||
1. `hermes tools` — check if toolset is enabled for your platform
|
||||
2. Some tools need env vars (check `.env`)
|
||||
3. `/reset` after enabling tools
|
||||
|
||||
### Model/provider issues
|
||||
1. `hermes doctor` — check config and dependencies
|
||||
2. `hermes auth` — re-authenticate OAuth providers (or `hermes auth add <provider>`)
|
||||
3. Check `.env` has the right API key
|
||||
4. **Copilot 403**: `gh auth login` tokens do NOT work for Copilot API. You must use the Copilot-specific OAuth device code flow via `hermes model` → GitHub Copilot.
|
||||
|
||||
### Changes not taking effect
|
||||
- **Tools/skills:** `/reset` starts a new session with updated toolset
|
||||
- **Config changes:** In gateway: `/restart`. In CLI: exit and relaunch.
|
||||
- **Code changes:** Restart the CLI or gateway process
|
||||
|
||||
### Skills not showing
|
||||
1. `hermes skills list` — verify installed
|
||||
2. `hermes skills config` — check platform enablement
|
||||
3. Load explicitly: `hermes -s name` (or the skill's own `/<name>` slash command)
|
||||
|
||||
### Gateway issues
|
||||
Check logs first:
|
||||
```bash
|
||||
grep -i "failed to send\|error" ~/.hermes/logs/gateway.log | tail -20
|
||||
```
|
||||
|
||||
Common gateway problems:
|
||||
- **Gateway dies on SSH logout**: Enable linger: `sudo loginctl enable-linger $USER`
|
||||
- **Gateway dies on WSL2 close**: WSL2 requires `systemd=true` in `/etc/wsl.conf` for systemd services to work. Without it, gateway falls back to `nohup` (dies when session closes).
|
||||
- **Gateway crash loop**: Reset the failed state: `systemctl --user reset-failed hermes-gateway`
|
||||
|
||||
### Platform-specific issues
|
||||
- **Discord bot silent**: Must enable **Message Content Intent** in Bot → Privileged Gateway Intents.
|
||||
- **Slack bot only works in DMs**: Must subscribe to `message.channels` event. Without it, the bot ignores public channels.
|
||||
- **Windows-specific issues** (`Alt+Enter` newline, WinError 10106, UTF-8 BOM config, line endings): see `references/windows-quirks.md`.
|
||||
|
||||
### Auxiliary models not working
|
||||
If `auxiliary` tasks (vision, compression, session_search) fail silently, the `auto` provider can't find a backend. Either set `OPENROUTER_API_KEY` or `GOOGLE_API_KEY`, or explicitly configure each auxiliary task's provider:
|
||||
```bash
|
||||
hermes config set auxiliary.vision.provider <your_provider>
|
||||
hermes config set auxiliary.vision.model <model_name>
|
||||
```
|
||||
|
||||
### "Reset permissions" / auto-approving everything
|
||||
See `references/security-privacy.md` — wipe the "Always allow" stores, don't touch yolo mode.
|
||||
|
||||
@@ -0,0 +1,137 @@
|
||||
# TUI Widgets — Live Panels for the Ink TUI Dock
|
||||
|
||||
Author widget apps for the Hermes TUI (`hermes --tui`): glanceable ambient
|
||||
panels docked above the status bar, or modal overlays that own the keyboard.
|
||||
Widgets are plain ESM files the TUI loads at startup — no build step, no
|
||||
repo changes. This skill does not cover desktop-app or web-dashboard
|
||||
widgets.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user asks for a live panel in the TUI (ticker, clock, countdown,
|
||||
status card, API-backed readout).
|
||||
- The user wants a custom modal tool (picker, calculator, viewer) bound to
|
||||
a slash command.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- The TUI must be in use (`hermes --tui`). Widgets do not render in the
|
||||
classic CLI or messaging platforms.
|
||||
- Network-backed widgets need whatever credentials their API needs; fetch
|
||||
failures must land as an error phase, never a crash.
|
||||
|
||||
## How to Run
|
||||
|
||||
1. Use `write_file` to create `~/.hermes/tui-widgets/<name>.mjs` (see
|
||||
`templates/clock.mjs` for a complete working widget).
|
||||
2. If the TUI is running it hot-loads the file within ~a second (the
|
||||
widgets directory is watched); `/widgets-reload` forces a rescan.
|
||||
3. The widget's id becomes its slash command automatically (`/<id>`), with
|
||||
its `help` in the `/` completion popover. No other registration exists.
|
||||
4. Auto-open (no command needed): end `register(sdk)` with
|
||||
`sdk.openWidget(app, app.init(''))` — the widget docks itself the moment
|
||||
the file loads. Only do this when the user asked for it; note it re-docks
|
||||
on every `/widgets-reload`.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
A widget file default-exports `register(sdk)`:
|
||||
|
||||
```js
|
||||
export default function register(sdk) {
|
||||
const { Box, Text, defineWidgetApp, h } = sdk
|
||||
|
||||
defineWidgetApp({
|
||||
id: 'clock', // slash command name
|
||||
help: 'live clock in the dock', // `/` completion metadata
|
||||
mode: 'ambient', // 'ambient' docks; 'modal' takes input
|
||||
init: arg => ({ label: arg.trim() || 'UTC' }), // null = print usage
|
||||
reduce: (state, { ch, key }) => (key.escape || ch === 'q' ? null : state),
|
||||
render: ({ state, t }) => h(sdk.Dialog, { width: 24 }, h(Text, { color: t.color.label }, state.label))
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
`sdk` contents: `defineWidgetApp`, `openWidget`, `updateWidget`, `isCtrl`,
|
||||
`React`, `h` (createElement — no JSX in .mjs), components `Box`, `Text`,
|
||||
`Dialog`, `Overlay`, `WidgetGrid`, `GridAreas`, and loaders `Shimmer`,
|
||||
`ShimmerRows`, `useShimmerPhase` — use `ShimmerRows` for loading phases
|
||||
instead of a bare "loading…" line.
|
||||
|
||||
Expand/collapse: `sdk.Accordion` — the same primitive the session panel's
|
||||
tool/skill sections use. `h(Accordion, { t, title: 'details', count: 3,
|
||||
defaultOpen: false }, body)` toggles on CLICK (works in ambient widgets,
|
||||
which receive no keys); modal apps may pass `open` + `onToggle` to drive it
|
||||
from reducer state instead.
|
||||
|
||||
Stable sizing (cards must NEVER resize while ticking):
|
||||
|
||||
- Give `Dialog` an explicit `width`; charts already return exactly the
|
||||
`width` you ask for (short series pad-left while history warms up).
|
||||
- Pad dynamic numbers: `String(v).padStart(6)` — `51 ms` → `112 ms` must
|
||||
not change the line length.
|
||||
- Keep row counts constant per phase; swap content, not structure.
|
||||
|
||||
Charts (pure string builders — color the result with theme tones):
|
||||
|
||||
- `sdk.sparkline(series, width?)` → `▂▃▅▇█▆` one-row trend
|
||||
- `sdk.sparkRows(series, width, rows)` → multi-row column chart (top line
|
||||
first) — the mission-control panel look; taller cells gain resolution
|
||||
- `sdk.gauge(ratio, width)` → `█████░░░` fill bar for a 0..1 value
|
||||
- `sdk.hbars(values, width)` → horizontal bar chart, one bar per value,
|
||||
eighth-block tips, scaled to the max
|
||||
|
||||
Keep a rolling series in component state (push per tick, cap ~120 samples)
|
||||
and render `sparkRows` for dashboard panels, `sparkline` for one-liners.
|
||||
|
||||
Contract essentials:
|
||||
|
||||
- `mode: 'ambient'` — captures no input, the command toggles it; `render`
|
||||
returns a CARD (usually `Dialog`), never `Overlay`. Placement via `zone` — every zone RESERVES real space (nothing ever
|
||||
paints over the transcript):
|
||||
- Docks (chrome rows): `dock-top` (under the top status bar),
|
||||
`dock-bottom` (default — above the bottom one).
|
||||
- Rails (side columns beside the transcript; text reflows around them):
|
||||
`top-left`, `top-right`, `bottom-left`, `bottom-right` — corner names
|
||||
pick the rail side and its top/bottom anchor. Set `width` on the app
|
||||
to the card's width (match your Dialog width; default 44) — the rail
|
||||
reserves exactly that many columns.
|
||||
Map the user's words to the nearest zone: "top right" → `top-right`,
|
||||
"above/next to the status bar" → a dock. Rails suit narrow cards
|
||||
(~30-46 cols); full-width or short-and-wide content belongs in a dock.
|
||||
- `mode: 'modal'` (default) — owns every keypress; `reduce` returns next
|
||||
state, the same reference to swallow a key, or `null` to close; `render`
|
||||
wraps content in `Overlay` for placement.
|
||||
- Async data: fire the fetch from `init`, land results with
|
||||
`sdk.updateWidget(app, fn)` — it no-ops if the widget was closed, so a
|
||||
late reply can never resurrect it.
|
||||
- Animation: own a timer inside a component via `React.useState` +
|
||||
`React.useEffect` (see the template); keep intervals ≥ 250ms.
|
||||
- Colors: ALWAYS theme tones (`t.color.primary/label/muted/ok/error/…`),
|
||||
never hardcoded hexes — widgets must survive `/skin` and light/dark.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Pick `id`, `mode`, and the state shape; keep state serializable.
|
||||
2. Write the file from the template; wire data via `init` + `updateWidget`.
|
||||
3. `/<id>` to launch (hot-loaded on write); relaunch `/<id>` to dismiss an
|
||||
ambient widget.
|
||||
4. Iterate: edit the file — it hot-reloads on save (last-writer-wins, the
|
||||
fresh definition shadows the old one). Relaunch `/<id>` to remount.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- No JSX and no bare imports in `.mjs` — everything comes from the `sdk`
|
||||
parameter; `h(...)` builds elements.
|
||||
- Don't ship a modal without a close path (`Esc`/`q` returning `null`).
|
||||
- Ambient widgets must stay small (≤ ~6 rows) — the dock sits between the
|
||||
transcript and the status bar.
|
||||
- A thrown `register()` is logged and skipped; check
|
||||
`~/.hermes/logs/tui_gateway_crash.log` if a widget never appears.
|
||||
|
||||
## Verification
|
||||
|
||||
Run `/widgets-reload` — the transcript line must list the file under
|
||||
`loaded:`. Then `/<id>`: an ambient widget appears docked right, above the
|
||||
status bar, while the composer keeps accepting input; `/<id>` again removes
|
||||
it.
|
||||
@@ -0,0 +1,212 @@
|
||||
# Webhook Subscriptions
|
||||
|
||||
Create dynamic webhook subscriptions so external services (GitHub, GitLab, Stripe, CI/CD, IoT sensors, monitoring tools) can trigger Hermes agent runs by POSTing events to a URL.
|
||||
|
||||
## Setup (Required First)
|
||||
|
||||
The webhook platform must be enabled before subscriptions can be created. Check with:
|
||||
```bash
|
||||
hermes webhook list
|
||||
```
|
||||
|
||||
If it says "Webhook platform is not enabled", set it up:
|
||||
|
||||
### Option 1: Setup wizard
|
||||
```bash
|
||||
hermes gateway setup
|
||||
```
|
||||
Follow the prompts to enable webhooks, set the port, and set a global HMAC secret.
|
||||
|
||||
### Option 2: Manual config
|
||||
Add to `~/.hermes/config.yaml`:
|
||||
```yaml
|
||||
platforms:
|
||||
webhook:
|
||||
enabled: true
|
||||
extra:
|
||||
port: 8644
|
||||
secret: "generate-a-strong-secret-here"
|
||||
```
|
||||
|
||||
Omitting `host` uses the dual-stack default and listens on both IPv4 and IPv6.
|
||||
Set a specific address only when you intentionally want to restrict the bind.
|
||||
|
||||
### Option 3: Environment variables
|
||||
Add to `${HERMES_HOME:-~/.hermes}/.env`:
|
||||
```bash
|
||||
WEBHOOK_ENABLED=true
|
||||
WEBHOOK_PORT=8644
|
||||
WEBHOOK_SECRET=generate-a-strong-secret-here
|
||||
```
|
||||
|
||||
After configuration, start (or restart) the gateway:
|
||||
```bash
|
||||
hermes gateway run
|
||||
# Or if using systemd:
|
||||
systemctl --user restart hermes-gateway
|
||||
```
|
||||
|
||||
Verify it's running:
|
||||
```bash
|
||||
curl http://localhost:8644/health
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
All management is via the `hermes webhook` CLI command:
|
||||
|
||||
### Create a subscription
|
||||
```bash
|
||||
hermes webhook subscribe <name> \
|
||||
--prompt "Prompt template with {payload.fields}" \
|
||||
--events "event1,event2" \
|
||||
--description "What this does" \
|
||||
--skills "skill1,skill2" \
|
||||
--deliver telegram \
|
||||
--deliver-chat-id "12345" \
|
||||
--secret "optional-custom-secret"
|
||||
```
|
||||
|
||||
Returns the webhook URL and HMAC secret. The user configures their service to POST to that URL.
|
||||
|
||||
### Filter or transform payloads before the agent runs
|
||||
|
||||
Two mechanisms narrow broad event streams (e.g. Todoist/GitHub fire on every update) so only relevant payloads wake the agent:
|
||||
|
||||
- **Declarative `filters`** (config.yaml routes only): list of conditions on payload fields, event type, or headers — operators `equals`, `not_equals`, `contains`, `exists`, `missing`, `in`, `in_file`, `regex`, with `all`/`any`/`not` grouping. Non-matching events are ignored with HTTP 200.
|
||||
- **Route scripts** (`--script` on subscribe, or `script:` on a config route): a script under `~/.hermes/scripts/` receives the payload as JSON on stdin. JSON stdout replaces the payload before prompt templating; empty stdout, `[SILENT]`, or a nonzero exit ignores the webhook. `.sh`/`.bash` run with bash, everything else with Python. Scripts cannot live outside `~/.hermes/scripts/` (path traversal is blocked).
|
||||
|
||||
```bash
|
||||
hermes webhook subscribe todoist-hermes \
|
||||
--prompt "Task changed: {payload.content}" \
|
||||
--script "todoist-hermes-label.py" \
|
||||
--deliver telegram --deliver-chat-id "12345"
|
||||
```
|
||||
|
||||
Full filter syntax: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/webhooks#payload-filters
|
||||
|
||||
### List subscriptions
|
||||
```bash
|
||||
hermes webhook list
|
||||
```
|
||||
|
||||
### Remove a subscription
|
||||
```bash
|
||||
hermes webhook remove <name>
|
||||
```
|
||||
|
||||
### Test a subscription
|
||||
```bash
|
||||
hermes webhook test <name>
|
||||
hermes webhook test <name> --payload '{"key": "value"}'
|
||||
```
|
||||
|
||||
## Prompt Templates
|
||||
|
||||
Prompts support `{dot.notation}` for accessing nested payload fields:
|
||||
|
||||
- `{issue.title}` — GitHub issue title
|
||||
- `{pull_request.user.login}` — PR author
|
||||
- `{data.object.amount}` — Stripe payment amount
|
||||
- `{sensor.temperature}` — IoT sensor reading
|
||||
|
||||
If no prompt is specified, the full JSON payload is dumped into the agent prompt.
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### GitHub: new issues
|
||||
```bash
|
||||
hermes webhook subscribe github-issues \
|
||||
--events "issues" \
|
||||
--prompt "New GitHub issue #{issue.number}: {issue.title}\n\nAction: {action}\nAuthor: {issue.user.login}\nBody:\n{issue.body}\n\nPlease triage this issue." \
|
||||
--deliver telegram \
|
||||
--deliver-chat-id "-100123456789"
|
||||
```
|
||||
|
||||
Then in GitHub repo Settings → Webhooks → Add webhook:
|
||||
- Payload URL: the returned webhook_url
|
||||
- Content type: application/json
|
||||
- Secret: the returned secret
|
||||
- Events: "Issues"
|
||||
|
||||
### GitHub: PR reviews
|
||||
```bash
|
||||
hermes webhook subscribe github-prs \
|
||||
--events "pull_request" \
|
||||
--prompt "PR #{pull_request.number} {action}: {pull_request.title}\nBy: {pull_request.user.login}\nBranch: {pull_request.head.ref}\n\n{pull_request.body}" \
|
||||
--skills "github-code-review" \
|
||||
--deliver github_comment
|
||||
```
|
||||
|
||||
### Stripe: payment events
|
||||
```bash
|
||||
hermes webhook subscribe stripe-payments \
|
||||
--events "payment_intent.succeeded,payment_intent.payment_failed" \
|
||||
--prompt "Payment {data.object.status}: {data.object.amount} cents from {data.object.receipt_email}" \
|
||||
--deliver telegram \
|
||||
--deliver-chat-id "-100123456789"
|
||||
```
|
||||
|
||||
### CI/CD: build notifications
|
||||
```bash
|
||||
hermes webhook subscribe ci-builds \
|
||||
--events "pipeline" \
|
||||
--prompt "Build {object_attributes.status} on {project.name} branch {object_attributes.ref}\nCommit: {commit.message}" \
|
||||
--deliver discord \
|
||||
--deliver-chat-id "1234567890"
|
||||
```
|
||||
|
||||
### Generic monitoring alert
|
||||
```bash
|
||||
hermes webhook subscribe alerts \
|
||||
--prompt "Alert: {alert.name}\nSeverity: {alert.severity}\nMessage: {alert.message}\n\nPlease investigate and suggest remediation." \
|
||||
--deliver origin
|
||||
```
|
||||
|
||||
### Direct delivery (no agent, zero LLM cost)
|
||||
|
||||
For use cases where you just want to push a notification through to a user's chat — no reasoning, no agent loop — add `--deliver-only`. The rendered `--prompt` template becomes the literal message body and is dispatched directly to the target adapter.
|
||||
|
||||
Use this for:
|
||||
- External service push notifications (Supabase/Firebase webhooks → Telegram)
|
||||
- Monitoring alerts that should forward verbatim
|
||||
- Inter-agent pings where one agent is telling another agent's user something
|
||||
- Any webhook where an LLM round trip would be wasted effort
|
||||
|
||||
```bash
|
||||
hermes webhook subscribe antenna-matches \
|
||||
--deliver telegram \
|
||||
--deliver-chat-id "123456789" \
|
||||
--deliver-only \
|
||||
--prompt "🎉 New match: {match.user_name} matched with you!" \
|
||||
--description "Antenna match notifications"
|
||||
```
|
||||
|
||||
The POST returns `200 OK` on successful delivery, `502` on target failure — so upstream services can retry intelligently. HMAC auth, rate limits, and idempotency still apply.
|
||||
|
||||
Requires `--deliver` to be a real target (telegram, discord, slack, github_comment, etc.) — `--deliver log` is rejected because log-only direct delivery is pointless.
|
||||
|
||||
## Security
|
||||
|
||||
- Each subscription gets an auto-generated HMAC-SHA256 secret (or provide your own with `--secret`)
|
||||
- The webhook adapter validates signatures on every incoming POST
|
||||
- Static routes from config.yaml cannot be overwritten by dynamic subscriptions
|
||||
- Subscriptions persist to `~/.hermes/webhook_subscriptions.json`
|
||||
|
||||
## How It Works
|
||||
|
||||
1. `hermes webhook subscribe` writes to `~/.hermes/webhook_subscriptions.json`
|
||||
2. The webhook adapter hot-reloads this file on each incoming request (mtime-gated, negligible overhead)
|
||||
3. When a POST arrives matching a route, the adapter formats the prompt and triggers an agent run
|
||||
4. The agent's response is delivered to the configured target (Telegram, Discord, GitHub comment, etc.)
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If webhooks aren't working:
|
||||
|
||||
1. **Is the gateway running?** Check with `systemctl --user status hermes-gateway` or `ps aux | grep gateway`
|
||||
2. **Is the webhook server listening?** `curl http://localhost:8644/health` should return `{"status": "ok"}`
|
||||
3. **Check gateway logs:** `grep webhook ~/.hermes/logs/gateway.log | tail -20`
|
||||
4. **Signature mismatch?** Verify the secret in your service matches the one from `hermes webhook list`. GitHub sends `X-Hub-Signature-256`, GitLab sends `X-Gitlab-Token`.
|
||||
5. **Firewall/NAT?** The webhook URL must be reachable from the service. For local development, use a tunnel (ngrok, cloudflared).
|
||||
6. **Wrong event type?** Check `--events` filter matches what the service sends. Use `hermes webhook test <name>` to verify the route works.
|
||||
@@ -0,0 +1,58 @@
|
||||
# Windows-Specific Quirks
|
||||
|
||||
Hermes runs natively on Windows (PowerShell, cmd, Windows Terminal, git-bash
|
||||
mintty, VS Code integrated terminal). Most of it just works, but a handful
|
||||
of differences between Win32 and POSIX have bitten us — document new ones
|
||||
here as you hit them so the next person (or the next session) doesn't
|
||||
rediscover them from scratch.
|
||||
|
||||
### Input / Keybindings
|
||||
|
||||
**Alt+Enter doesn't insert a newline** — Windows Terminal (and mintty) grab it
|
||||
for fullscreen before prompt_toolkit sees it. Use **Ctrl+Enter** instead (the
|
||||
CLI binds it to newline on Windows; raw Ctrl+J does the same, harmlessly).
|
||||
To inspect how your terminal reports a keystroke, run
|
||||
`python scripts/keystroke_diagnostic.py` from the repo root.
|
||||
|
||||
### Config / Files
|
||||
|
||||
**HTTP 400 "No models provided" on first run** — `config.yaml` was saved with
|
||||
a UTF-8 BOM (Notepad does this). Re-save as UTF-8 without BOM;
|
||||
`hermes config edit` writes correctly.
|
||||
|
||||
### `execute_code` / Sandbox
|
||||
|
||||
**WinError 10106** from the sandbox child process — it can't create an
|
||||
`AF_INET` socket. Root cause is usually Hermes's env scrubber dropping
|
||||
`SYSTEMROOT`/`WINDIR`/`COMSPEC` (Python's `socket` needs `SYSTEMROOT` to find
|
||||
`mswsock.dll`), not a broken Winsock LSP. The `_WINDOWS_ESSENTIAL_ENV_VARS`
|
||||
allowlist in `tools/code_execution_tool.py` covers it; if you still hit it,
|
||||
echo `os.environ` inside an `execute_code` block to confirm `SYSTEMROOT` is set.
|
||||
|
||||
### Testing on Windows
|
||||
|
||||
`scripts/run_tests.sh` is POSIX-only (expects `.venv/bin/activate`); the
|
||||
Hermes-installed `venv/Scripts/` has no pip/pytest (stripped for size).
|
||||
Install pytest into a system Python and run directly (the repo no longer
|
||||
uses pytest-xdist; the canonical runner does per-file subprocess isolation,
|
||||
which the POSIX-only wrapper handles):
|
||||
|
||||
```bash
|
||||
"/c/Program Files/Python311/python" -m pip install --user pytest pyyaml
|
||||
export PYTHONPATH="$(pwd)"
|
||||
"/c/Program Files/Python311/python" -m pytest tests/foo/test_bar.py -v --tb=short
|
||||
```
|
||||
|
||||
(POSIX-only tests need skip guards — see the cross-platform guard list in
|
||||
`references/contributor-guide.md`.)
|
||||
|
||||
### Path / Filesystem
|
||||
|
||||
**Line endings.** Git may warn `LF will be replaced by CRLF`. Cosmetic — the
|
||||
repo's `.gitattributes` normalizes. Don't let editors auto-convert committed
|
||||
POSIX-newline files to CRLF.
|
||||
|
||||
**Forward slashes work almost everywhere.** `C:/Users/...` is accepted by
|
||||
every Hermes tool and most Windows APIs. Prefer forward slashes in code
|
||||
and logs — avoids shell-escaping backslashes in bash.
|
||||
|
||||
Reference in New Issue
Block a user