Hermes Curator Hard-Deletes User Skills — No Consent Gate, No Recovery
#50875 — P2: A cron-scheduled data destroyer that's already wiped 80+ user-authored skills
Issue Summary
The curator subsystem runs on a weekly cron schedule by default with zero user notification, no approval gate before destructive actions, and uses skill_manage(action='delete') which permanently bypasses the archive. The result is irreversible data loss for user-created skills. This is structural, not a logic bug — even if consolidation were perfect, the design gives users no visibility, no consent, and no recovery.
Observed Impact
Over 7 curator runs (May 8 – June 12, 2026):
- 52 skills pruned in the June 12 run alone — 80+ total across all runs
- Multiple user-authored production workflow skills hard-deleted (scripts, checklists, format guides)
hermes curator restorereturns "not found in archive" — the June runs switched from archive (recoverable) toskill_manage(action='delete')(unrecoverable) with no documented changelog or migration notice- User had no awareness the curator existed — no onboarding step, no first-run disclosure, no opt-in
prune_builtins: trueis the default — user-created skills are not distinguished from auto-generated ones- Wrong consolidation targets: two semantically unrelated skills absorbed because they shared a tag — complete loss, wrong skill left standing
Three Distinct Gaps
1. Hard Deletes Bypass Archive
skill_manage(action='delete') writes no archive. Rollback infrastructure is irrelevant. Once deleted, gone forever.
2. No Consent or Notification
Shipped with sweeping delete powers on cron, zero disclosure. Users lose weeks of iterated work with no log, no message, no way to know it happened.
3. Wrong Consolidation Target
Domain mismatch, not just subfile loss. Two semantically unrelated skills absorbed because they shared a tag — different failure from #44760.
Related Issues
| Issue | Severity | Description |
|---|---|---|
| #47688 | P1 | Curator LLM consolidation mutates/deletes skills |
| #44760 | P2 | Silently loses reference subfiles during consolidation |
| #44658 | P2 | Rollback fails on symlink snapshots |
| #41444 | P3 | Feature proposal for confirmation gate (unimplemented) |
Why This Matters
This is exactly the kind of "production trust" issue the reviews site should highlight. A cron-scheduled, silent, irreversible data destroyer that ships enabled-by-default is the antithesis of production-readiness. Users who invested weeks iterating on workflow skills wake up to find them gone — with no warning, no log, and no recovery path. The switch from archive (recoverable) to hard-delete (unrecoverable) with no changelog or migration notice is especially concerning.
Key takeaway: The curator subsystem has sweeping delete powers, runs on cron by default, provides zero user notification, and permanently destroys user data. Four related issues (#47688 P1, #44760 P2, #44658 P2, #41444 P3) demonstrate this is a systemic design problem, not an isolated bug.
Source Evidence
GitHub Issue: NousResearch/hermes-agent#50875
Opened: June 22, 2026 | Reporter: @owynter | Labels: P2, comp/agent, tool/skills, type/bug
Hermes: v0.17.0 (b1b2027) | Python: 3.11.15