Bug Description

A critical bug in the cronjob tool causes mass corruption of model and provider fields across multiple cron jobs when performing rapid consecutive updates to a single job. This results in affected jobs falling back to safety refusal mode instead of processing their intended prompts.

Impact

• Scope: 15 out of 24 cron jobs (62%) affected in single incident
• Fields: Only model and provider fields corrupted to null
• Consequence: Jobs enter safety refusal mode, effectively breaking critical automation
• Services affected: Email intake, wiki processing, health checks, backups, digests

Steps to Reproduce

1. Perform rapid consecutive cronjob(action='update') calls on the same job
2. Ensure updates modify different field combinations but do NOT explicitly set model/provider
3. Example sequence that triggered the bug:

# Update 1: Multiple fields
cronjob(action='update', job_id='b6e482e6fa25', 
        skills=['hermes-memory-compaction'],
        enabled_toolsets=['terminal', 'file', 'skills', 'memory'],
        prompt='...')

# Update 2: Single field  
cronjob(action='update', job_id='b6e482e6fa25',
        enabled_toolsets=['terminal', 'file', 'skills'])
        
# Update 3: Single field
cronjob(action='update', job_id='b6e482e6fa25',
        prompt='...')

Expected Behavior

• Only the explicitly updated fields should be modified
• model and provider fields should remain unchanged if not specified in update
• Updates to one job should not affect other jobs

Actual Behavior

• model and provider fields of multiple unrelated jobs corrupted to null
• 15 jobs affected when only 1 job was being updated (cascade corruption)
• Jobs with null model/provider fall back to safety refusal mode

Technical Analysis

Evidence of Cascade Bug

• Jobs updated: 1 job (b6e482e6fa25)
• Jobs affected: 15 jobs (including the updated job + 14 others)
• Timing: Single modification timestamp on jobs.json (2026-05-09 13:50)
• Field pattern: Only model and provider fields affected; all other fields intact

Likely Root Causes

1. Race Condition: Rapid consecutive updates create file-level race condition during load_jobs() → modify → save_jobs() cycle
2. Auto-Repair Corruption: JSON parsing issue triggers auto-repair mechanism in load_jobs() lines 359-360, saving incomplete data
3. Schema Processing Bug: Hidden normalization code path that assumes model/provider should be null under specific conditions

Environment

• Hermes Agent Version: Latest (2026-05-09)
• Platform: macOS
• Python Version: 3.11.15
• Config: model.default: gpt-5.5, model.provider: openai-codex

Code Paths Investigated

• cron/jobs.py: update_job(), save_jobs(), load_jobs() auto-repair mechanism
• tools/cronjob_tools.py: Tool wrapper with proper null-safety checks
• No relevant error logs found - corruption was completely silent

Workaround Applied

Manually restored model: "gpt-5.5", provider: "openai-codex" to all affected jobs.

Files for Investigation

• ~/.hermes/cron/jobs.json - Job storage
• cron/jobs.py lines 359-360 (auto-repair mechanism)
• cron/jobs.py lines 595+ (update_job method)

Additional Context

Full technical analysis and session evidence available in generated bug report. This is a production-affecting issue that corrupted live automation jobs during routine memory compaction operations.