Summary

Adds profile management so users can run multiple fully isolated Hermes instances on the same machine. Each profile has its own config, API keys, memory, sessions, skills, gateway, cron, and logs — completely independent from other profiles.

Related to #896 (multi-agent architecture), but orthogonal — profiles provide infrastructure-level isolation (separate gateways, separate secrets), while #896 provides application-level routing within a single profile.

The Problem

Today, running two Discord bots on the same machine requires manually juggling HERMES_HOME env vars. Worse, hermes gateway stop uses a greedy ps aux scan that kills ALL gateway processes regardless of which instance they belong to.

What This Does

New: hermes_cli/profiles.py (~280 lines)

• Profile CRUD: create, list, clone, delete
• Profiles live at ~/.hermes/profiles/<name>/, each a full HERMES_HOME directory
• Clone support: --clone default copies config.yaml + .env; --clone-data also copies memories/skills/skins
• Gateway collision detection (refuses to delete a profile with a running gateway)
• Active profile detection from HERMES_HOME

Modified: hermes_cli/main.py

• --profile/-p flag pre-parsed before any module imports — critical because 30+ modules cache HERMES_HOME at import time via module-level constants
• New profile subcommand: hermes profile create|list|delete|show

Fixed: hermes_cli/gateway.py

• find_gateway_pids() now uses the HERMES_HOME-scoped PID file instead of a greedy ps aux scan
• This prevents hermes -p work gateway stop from killing the personal profile's gateway
• Legacy fallback scan retained for backward compat with old PID-less installs

Modified: hermes_cli/banner.py

• Shows active profile name in CLI banner when not using the default profile

Usage

# Create profiles
hermes profile create work-bot
hermes profile create personal-bot --clone default    # clone config + API keys

# Configure each independently
hermes -p work-bot setup                              # separate .env, model, etc.
hermes -p personal-bot setup

# Run independent gateways (separate Discord/Telegram bots)
hermes -p work-bot gateway install && hermes -p work-bot gateway start
hermes -p personal-bot gateway install && hermes -p personal-bot gateway start

# Chat in a specific profile
hermes -p work-bot

# See all profiles
hermes profile list

Architecture

Each profile is just a HERMES_HOME directory. The -p flag sets HERMES_HOME before anything loads, so all downstream code naturally scopes:

The default profile is ~/.hermes itself — zero migration, fully backward compatible.

Tests

• 40 new tests in test_profiles.py: validation, create, clone, delete, list, isolation, gateway PID scoping, systemd service name scoping
• 3 new tests in test_gateway_pid_scoping.py: PID-file based lookup, cross-profile isolation
• Full suite: 5278 passed, 0 new failures

Design Decisions

1. Pre-import flag parsing — --profile is extracted from sys.argv before any hermes modules import, because 30+ files cache HERMES_HOME at module level
2. Profiles root at ~/.hermes/profiles/ — anchored to $HOME, not $HERMES_HOME, so profiles are always discoverable
3. PID-file first for gateway stop — eliminates the main multi-profile collision vector while keeping a legacy fallback
4. Clone as opt-in — fresh profiles start empty; --clone copies config; --clone-data copies memories/skills

Relationship to PR #896

PR #896 adds named agents within a single Hermes install (routing, tool policies, personas). This PR adds isolated profiles — separate installs that don't share anything. They compose naturally:

Profile "work" (HERMES_HOME=~/.hermes/profiles/work)
  ├── Agent "main" (Claude, full tools)
  └── Agent "coder" (Codex, coding tools only)

Profile "personal" (HERMES_HOME=~/.hermes/profiles/personal)
  └── Agent "assistant" (Gemini Flash)