openclaw - 💡(How to fix) Fix [Feature]: Split jobs.json into per-job config files [1 participants]

Summary

Allow cron jobs to be stored as individual JSON files (e.g., ~/.openclaw/cron/jobs/<job-id>.json) instead of a single monolithic jobs.json file.

Problem to solve

Currently all cron jobs are stored in a single ~/.openclaw/cron/jobs.json file (~22KB with 10+ jobs). This creates several issues:

1. Readability: Hard to review or manually edit a specific job buried in a large JSON array
2. Concurrent write risk: Multiple operations (cron edit, cron run state updates) all read/write the same file, increasing the chance of corruption
3. Version control unfriendly: Any change to one job shows a diff on the entire file, making git history noisy
4. Scaling concern: As users add more jobs with long message payloads, the file grows unbounded

Proposed solution: Store each job as a separate file under ~/.openclaw/cron/jobs/ (e.g., jobs/<job-id>.json or jobs/<job-name>.json), and have the gateway discover all job files in the directory on startup. Keep backward compatibility by auto-migrating the existing jobs.json on first run.

This pattern is common in systemd (one unit file per service), nginx (sites-available), and crontab.d.

Proposed solution

Store each cron job as an individual JSON file under ~/.openclaw/cron/jobs/ directory:

~/.openclaw/cron/jobs/ ├── 6d185325-news-ai-daily.json ├── f3493837-a-stock-mid.json ├── 3bcc85c8-short-trade.json └── ...

File naming: <job-id>-<job-name>.json for easy identification.

On startup, the gateway scans the directory and loads all .json files. CLI commands (cron add/edit/delete) operate on individual files instead of the monolithic jobs.json.

For backward compatibility:

• On first run after upgrade, auto-migrate existing jobs.json → individual files
• If jobs.json exists and jobs/ directory is empty, fall back to jobs.json

Alternatives considered

1. Keep single jobs.json but add file locking — reduces corruption risk but doesn't solve readability, git-friendliness, or scaling issues.

2. Use a SQLite database — more robust but harder for users to manually inspect/edit, and overkill for typically <20 jobs.

3. YAML instead of JSON — slightly more readable but doesn't solve the single-file problem; also adds a parser dependency.

Individual files is the simplest approach that solves all the pain points while staying consistent with how other tools handle similar configs (systemd units, nginx sites-available, cron.d).

Impact

Affected: All users with 5+ cron jobs, especially power users who manage 10-15 scheduled tasks Severity: Medium — annoying, increases risk of config corruption Frequency: Daily — every cron edit/add/run touches the single file Consequence: Manual editing is error-prone (one misplaced comma breaks all jobs); git diffs are noisy; agent-driven edits (via python/jq) must read-write the entire file, risking data loss on concurrent access

Evidence/examples

Current state: a single jobs.json at ~/.openclaw/cron/jobs.json holding 13 jobs, 22KB+

$ ls -la ~/.openclaw/cron/jobs.json -rw------- 1 root root 23856 Apr 23 09:01 jobs.json

Prior art:

• systemd: one .service file per unit in /etc/systemd/system/
• nginx: one .conf per site in /etc/nginx/sites-available/
• cron.d: one file per job in /etc/cron.d/
• GitHub Actions: one .yml per workflow in .github/workflows/

All follow the same pattern: one config file per job/unit for isolation and maintainability.

Additional information

No response