fix(cron): allow cron jobs to use the memory() tool

[ValentinSergief]

Problem

Cron jobs are hardcoded with skip_memory=True at agent creation time, preventing the memory() tool from working in any cron job. The comment in cron/scheduler.py:1801 states: "Cron system prompts would corrupt user representations."

This makes cron unable to perform its most natural automation tasks — memory health checks, periodic pruning, duplicate consolidation, or any scheduled maintenance that touches memory.

Analysis

The upstream concern ("corrupt user representations") is already addressed by existing safety mechanisms that work regardless of call context:

Mechanism	Location	What it protects
_detect_external_drift()	tools/memory_tool.py:522	Detects malformed writes via round-trip mismatch and entry-size overflow. Creates .bak.<timestamp> before refusing the mutation.
Atomic write + self-validating format	tools/memory_tool.py:578	Writes use atomic temp-file + rename. The §-delimited format is enforced on every write.

Cron is Hermes' automation surface — scheduled health checks, memory pruning, data maintenance, and cleanup tasks all need memory access. A cron job cannot write to memory spontaneously any more than a normal chat can: it requires an explicit tool call through run_conversation(), governed by the same tool validation and drift detection.

Fix

1 file, +1/−1. Replaces the hardcoded ban with skip_memory=False, relying on the existing drift detector as the real safety net. Cron jobs that misuse memory will be caught and backed up like any other session.

Cross-Platform

No platform-specific code. Pure configuration change at agent creation time.

Testing

1. Schedule a cron job with a prompt that invokes the memory() tool (e.g. "check my memory for issues")
2. Confirm memory() read works and write succeeds where intended
3. Confirm _detect_external_drift() still catches and backs up malformed writes

Fixes #43367

[alt-glitch]

Competing with #34098 (per-job memory_enabled) for cron memory access — a saturated cluster also including #33444 and #9802. This PR flips skip_memory=False globally rather than gating per-job. Marking duplicate of the canonical open PR; maintainers can pick the opt-in vs always-on approach. Fixes #43367.

[liuhao1024]

Semantic corruption vs. file-level integrity

The PR argues that `_detect_external_drift()$ is "the real safety net" that replaces the need for `skip_memory=True`. This conflates two different classes of corruption:

What `_detect_external_drift()$ protects against (file-level):

1. Round-trip mismatch — re-parsing and re-serializing produces different bytes
2. Entry-size overflow — a single parsed entry exceeds the char limit

What it does NOT protect against (semantic):
A cron job running with a different system prompt (automation-focused, not user-representative) can write perfectly well-formed entries that are semantically wrong for a user's memory store. For example:

• "The user wants automated daily reports at 9am" (the cron's prompt, not the user's preference)
• "Cron health check completed successfully" (operational noise, not user representation)
• "Model X works best for summarization" (the cron's opinion, not the user's)

All of these pass `_detect_external_drift()$ cleanly — the file format is correct, the entry size is within limits. But they pollute the user's `user` memory (which feeds the system prompt in every subsequent session).

The original comment `# Cron system prompts would corrupt user representations$ was about this semantic class, not file-level corruption.

Suggestion: Instead of flipping the global flag, consider a more targeted approach:

1. Keep `skip_memory=True$ as the default for cron
2. Add a per-job config option `allow_memory: true$ for jobs explicitly designed for memory maintenance
3. Or scope cron memory writes to a separate `cron` target (not `user$ or `assistant$)

This lets memory-maintenance cron jobs work while protecting user representations from automated pollution.

[ValentinSergief]

Thank you both for the thoughtful review — @liuhao1024's semantic-corruption point is exactly right, and @alt-glitch's cluster identification was spot-on.

I'm closing this PR. A new implementation is being prepared that:

• Sets skip_memory=False (cron jobs CAN read memory context — useful for context-aware automation)
• Adds write guards at both tool dispatch sites blocking add/replace/remove for cron sessions by default
• Complements fix(cron): allow per-job memory_enabled so cron jobs can opt into the memory system #34098 as the per-job opt-in override for trusted memory-maintenance jobs

This addresses liuhao1024's concern about semantic pollution (writes blocked by default) while enabling the memory-awareness that #43367/#9763/#34094/#38647 all request. The new PR will link here.