Summary

All cron jobs are now in a single file. That makes GitOps difficult. Proposing to also have a directory (jobs.d/?) for one file per job.

Problem to solve

Cron jobs are stored in a single ~/.openclaw/cron/jobs.json. This makes declarative management painful in NixOS/GitOps setups — there's no clean way to symlink individual job definitions from a git repo, and a fresh deploy requires recreating jobs manually or via a custom merge script.

Proposed solution

Support a jobs.d/ directory alongside (or instead of) jobs.json. Each *.json file in the directory represents one job — same schema as an entry in jobs.json. Gateway loads all files at startup.

Config:

cron: {
storeDir: "~/.openclaw/cron/jobs.d",
}

With per-file storage, a NixOS activation script becomes trivial:

ln -sfn ~/nixos-config/crons/daily-report.json ~/.openclaw/cron/jobs.d/daily-report.json

No merge scripts, no state management — just symlinks. This mirrors patterns already common in the ecosystem: conf.d/, systemd drop-ins, nginx sites-enabled/, etc.

Alternatives considered

Current workaround:

Using a Python activation script that merges declarative job definitions into jobs.json on every nixos-rebuild switch, preserving runtime fields (id/createdAtMs/state) for existing jobs. Works, but more complexity than a first-class GitOps use case should need.

Impact

Affected: user who wants to add/remove/edit cron jobs
Severity: annoying
Frequency: no tracking of cron jobs in git or complicated Python script to manage them
Consequence: difficulty tracking cron jobs in git

Evidence/examples

No response

Additional information

No response