Feature request: Hermes Agent session monitoring (hardened design, revisit #139)

[kouyichi]

Feature request: Hermes Agent session monitoring (revisit after #139)

Hermes Agent by Nous Research is an open-source AI agent framework in the same category as Claude Code / Codex CLI / OpenCode (local TUI + gateway, per-session token accounting, model-agnostic). It is widely deployed in terminal and desktop workflows, and its sessions are fully discoverable from local process + SQLite state — exactly abtop's model.

A previous attempt, PR #139 ("feat: add Hermes Agent session collector"), was closed with security feedback: it generated Python source with interpolated DB paths/session IDs, stored transcript text (initial prompts, assistant text, tool-call args) without the collector redaction model, and wrote predictable temp SQL files. I agree with all of that feedback — this issue proposes a smaller, hardened design that addresses each point:

• No dynamic code generation, no external interpreter, no temp files. Read ~/.hermes/state.db (or HERMES_HOME) read-only in-process via rusqlite (bundled SQLite) — same privacy posture as the existing collectors, zero shell surface, works on macOS/Linux/Windows without requiring a sqlite3/Python install.
• Process discovery without string interpolation. Hermes runs one tui_gateway.slash_worker --session-key <id> process per active session; matching is done by parsing already-scanned process command lines (the same SharedProcessData the other collectors use), never by building scripts.
• Follow the existing privacy/redaction model from the start. Every DB-sourced string (title, cwd, chat tail, tool args) goes through sanitize_terminal_text → redact_secrets → truncation, exactly like the OpenCode/Claude collectors.
• No symlink-following, fail-closed on the DB path, readonly connection only, results cached on the slow tick like OpenCodeCollector.

Scope would be the same feature set as the table in #139: session discovery, token tracking (input/output/cache from the sessions table), status detection, context-window % (model lookup table), child processes, git status. Rate limits are N/A (Hermes doesn't expose them).

Happy to open a PR implementing this design — just want to confirm the direction (in-process rusqlite vs. staying on the sqlite3-CLI pattern) before writing it.