TL;DR

hermes sessions delete <id> (and hermes sessions prune) remove the SQLite row, the <id>.jsonl transcript, and any request_dump_<id>_*.json files — but silently leave the per-session session_<id>.json transcript dump orphaned on disk. The cause is a literal filename-prefix mismatch between the writer (session_<id>.json) and the cleanup helper (<id>.json). Path.unlink(missing_ok=True) swallows the resulting "file not found", so no error surfaces.

Where

• Writer (uses session_ prefix):
  • run_agent.py:1666 — self.session_log_file = self.logs_dir / f"session_{self.session_id}.json"
  • cli.py:5305 — self.agent.logs_dir / f"session_{new_session_id}.json"
• Remover (no prefix):
  • hermes_state.py::_remove_session_files, ~lines 2014–2038:

    for suffix in (".json", ".jsonl"):
        p = sessions_dir / f"{session_id}{suffix}"
        try:
            p.unlink(missing_ok=True)
        except OSError:
            pass

• Callers (both pass sessions_dir correctly, so the path itself does get exercised):
  • delete_session() → hermes_state.py:2070
  • prune_sessions() → hermes_state.py:2126
  • prune_empty_ghost_sessions() → hermes_state.py:718
  • CLI dispatch: hermes_cli/main.py:9896 (delete), :9911 (prune)

What gets cleaned vs. left behind

hermes sessions delete <id> removes:

Reproduction (conceptual — no live delete required)

The bug is observable from the on-disk filename pattern alone, without needing to delete anything:

$ ls ~/.hermes/sessions/ | head
20260505_102819_5b83f0b8.jsonl              ← transcript log (no prefix)
session_20260505_102819_5b83f0b8.json       ← per-session JSON (with "session_" prefix)

Every persisted session writes session_<id>.json. The deleter constructs <id>.json (no prefix) and silently misses every time, since no such file is ever created.

Suggested fix

Either is fine; pick whichever matches the project's intent:

Option A — make the deleter match the writer:

for suffix in (".json", ".jsonl"):
    if suffix == ".json":
        p = sessions_dir / f"session_{session_id}.json"
    else:
        p = sessions_dir / f"{session_id}{suffix}"
    p.unlink(missing_ok=True)

Option B — drop the session_ prefix in the writer (more invasive; risks breaking any external tooling that reads session_*.json by that pattern).

Option A is the minimal safe fix.

Impact

Low severity but cumulative. Each leaked file is ~80–150 KB (per-session transcript dump, including system prompt and tool definitions). On long-running installs that periodically prune sessions, the disk cost grows without bound, and the orphans become unattributable once the matching SQLite row is gone (no more title/preview to identify them).

Environment

• Hermes Agent v0.12.0 (2026.4.30)
• HEAD at the time of writing: 87b113c2e3d89643f877c8273517c2a48a22253d (current origin/main)
• Platform Linux, Python 3.11.15
• Discovery context Operator investigation while diagnosing ~/.hermes/sessions/ directory hygiene; no live delete was performed against real sessions — the bug is fully apparent from source-reading combined with on-disk filename patterns. Happy to run a live confirmation against a sacrificial session if useful, but the source citations make the mismatch unambiguous.