Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [BUG] Agents bypass internal cron scheduler, modify system crontab directly [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#25271•Fetched 2026-05-14 03:47:43
View on GitHub
Comments
1
Participants
1
Timeline
7
Reactions
0
Author
fwendsfwends
Participants
fwendsfwends
Timeline (top)
labeled ×5commented ×1cross-referenced ×1

Error Message

  1. OR: Config flag: Add a config option that, when enabled, intercepts any crontab command before it reaches the shell and returns a clear error directing the agent to use the Hermes cron UI instead.

Root Cause

tools/skills_guard.py has a persistence_cron pattern that detects crontab references, but this guard only fires during skill installation/scanning — it does NOT block arbitrary shell commands executed via the terminal tool.

There is no runtime guard that prevents agents from running crontab commands directly.

Fix Action

Fixed

PR fix notes

PR #25284: fix(approval): block crontab commands in terminal tool dangerous-pattern guard

Description (problem / solution / changelog)

Summary

Block crontab commands in the terminal tool's dangerous-pattern guard so agents use Hermes's internal cron scheduler instead of modifying the OS crontab.

Root Cause

DANGEROUS_PATTERNS in tools/approval.py gates destructive shell commands (rm -rf, git reset --hard, mkfs, etc.) but does not include crontab. Agents can therefore run crontab -r (wipe all entries), crontab - (stdin replace), crontab -e, and pipe-to-crontab patterns via the terminal tool, bypassing the internal scheduler and destroying the user's actual system crontab.

A related PR (#14924) partially covers this by adding crontab -e/-u patterns, but it has been open for 3 weeks with zero reviews, zero comments, and no CI checks (likely first-time contributor gate). That PR also does not cover crontab -r or crontab - (stdin replace), which are the destructive patterns reported in the issue.

Fix

Add \bcrontab\b to DANGEROUS_PATTERNS — matches any crontab invocation. The word boundary prevents false positives on identifiers like mycrontab_tool.

Code Intelligence

  • Analyzed: detect_dangerous_command (callers: 8+, callees: _normalize_command_for_detection, DANGEROUS_PATTERNS_COMPILED)
  • Blast radius: LOW — adds one entry to a pattern list; no behavioral change to existing patterns
  • Related patterns: PR #14924 (partial, stuck), tools/skills_guard.py line 228 (skill-scan-only crontab detection)

Regression Coverage

6 new tests in TestDetectDangerousCrontab:

  • crontab -r (remove all)
  • crontab - (stdin replace)
  • crontab -e (edit)
  • crontab -l (list — also blocked)
  • pipe-to-crontab pattern
  • word boundary (negative — mycrontab_tool does not trigger)

Testing

tests/tools/test_approval.py::TestDetectDangerousCrontab — 6/6 passed
tests/tools/test_approval.py + test_hardline_blocklist.py + test_yolo_mode.py — 279/279 passed
tests/tools/test_hardline_blocklist.py + test_yolo_mode.py + test_cron_approval_mode.py — 143/143 passed

Fixes [BUG] Agents bypass internal cron scheduler, modify system crontab directly #25271

Changed files

  • tests/tools/test_approval.py (modified, +33/-0)
  • tools/approval.py (modified, +5/-0)

Code Example

The cron system is internal (JSON file-based scheduler ticked by the gateway),
so no external crontab executable is required.
RAW_BUFFERClick to expand / collapse

Problem

Hermes agents are running crontab commands directly via the terminal tool, bypassing Hermes's internal JSON-based cron scheduler. This is destructive — agents use crontab -r and similar commands which wipe the user's actual macOS system crontab, causing real damage.

Expected Behavior

Hermes ships with its own internal cron scheduler (JSON file-based, ticked by the gateway). The cronjob tool at http://127.0.0.1:9000/cron provides a UI for managing Hermes crons. No agent should ever need to touch the system crontab.

From tools/cronjob_tools.py:

The cron system is internal (JSON file-based scheduler ticked by the gateway),
so no external crontab executable is required.

What Actually Happens

Despite Hermes having a proper internal scheduler, agents continue to use:

  • crontab -l to list crontab
  • crontab -r to remove entries
  • (crontab -l 2>/dev/null | grep -v "..."; echo "...") | crontab - to add entries

This modifies the user's actual macOS crontab, not Hermes's internal scheduler.

Impact

  • User's legitimate system cron jobs are being deleted or overwritten
  • The internal Hermes cron system at http://127.0.0.1:9000/cron is being ignored
  • No guard exists to prevent crontab commands from executing via terminal tool

Root Cause

tools/skills_guard.py has a persistence_cron pattern that detects crontab references, but this guard only fires during skill installation/scanning — it does NOT block arbitrary shell commands executed via the terminal tool.

There is no runtime guard that prevents agents from running crontab commands directly.

Suggested Fix

  1. Runtime crontab block: Add crontab detection to the terminal tool's dangerous-command guard (similar to rm -rf, mkfs, etc.) so it blocks crontab execution at the shell level, not just in skill content.

  2. OR: Config flag: Add a config option that, when enabled, intercepts any crontab command before it reaches the shell and returns a clear error directing the agent to use the Hermes cron UI instead.

  3. Document the internal scheduler: Ensure agents can find the Hermes cron UI without having to guess or use system crontab.

User Context

  • User has explicitly told agents multiple times to use http://127.0.0.1:9000/cron instead of system crontab
  • Agents keep ignoring this and continue modifying the system crontab
  • This has caused real damage to the user's machine setup

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#installation#response parsing#generation error#database connection#vector store

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix [BUG] Agents bypass internal cron scheduler, modify system crontab directly [1 pull requests, 1 comments, 1 participants]