Summary

openclaw cron add (and cron edit) silently accept new jobs whose name collides with an existing job's name. Two distinct rows with identical names land in jobs.json, each with its own id, schedule, enabled, etc. Default cron list only renders one of them when their enabled differ, hiding the divergence from the operator.

Repro

# starting with a clean cron store
openclaw cron add --name foo --message 'a' --interval 30m
openclaw cron add --name foo --message 'b' --interval 30m
openclaw cron list                # may show only one
openclaw cron list --all --json | jq '[.jobs[] | select(.name=="foo")] | length'
# => 2

Observed in the wild

Found during a config audit on a production deployment:

JOB: 'imessage-30min-scan' id=a0394d62-… enabled=False createdAtMs=1776885941338 msg_len=1316
JOB: 'imessage-30min-scan' id=26d0be12-… enabled=True  createdAtMs=1776895555114 msg_len=1289

The older row was disabled and superseded ~2.7h later by a re-add with a different delivery channel. Both lived in jobs.json indefinitely; only the enabled one ran. Behavior was correct here because the disabled state acted as the dedup signal — but if the operator had left both enabled, the job would silently fire twice per cycle with two divergent prompts. There is no UI surface today that exposes that risk.

Why this hurts

1. Silent dual-fire. Two enabled rows with the same name → 2× executions per cycle, 2× cost, divergent prompts (one stale).
2. Default cron list hides the case. Disabled rows are filtered out unless --all is passed, so an operator looking at the list won't see the duplicate.
3. Fix-by-name is ambiguous. PR #28791 (fix(cron): allow removing jobs by name in addition to ID) implicitly assumes uniqueness — cron rm <name> resolves only when names are unique. Allowing duplicates via add/edit undermines that assumption.

Proposed UX

cron add and cron edit SHOULD treat name as unique within an agent's job set:

• Default: refuse the operation with an actionable error (Error: a cron job named 'foo' already exists (id=…). Use --replace to overwrite, --rename to choose a new name, or 'cron rm' first.).
• Opt-in override: --replace flag overwrites the existing row in place (preserving id, replacing other fields). Mirrors the semantics of patch-herd-cron.py's byte-equality refresh model.
• Defensive listing: consider showing duplicate-name groups in cron list --all with a warning marker so operators discover legacy duplicates left over from before the validation lands.

The check belongs in the gateway-side cron-add handler (so it covers CLI, the cron agent tool, and any future surfaces) — not just the CLI-side argument parser.

Code pointers (gateway 2026.4.14, hash db2jj6bs2…323493fa)

Bundled output, unminified — easy to map to source:

• dist/cron-cli-AozygQuG.js — CLI handler (the add / edit entry points). Lines ~380, ~478, ~490 reference payload.lightContext etc.
• dist/jobs-BuytQ0ly.js — job storage layer. Lines ~616, ~637 mutate the job list. Likely where the uniqueness check belongs.
• dist/openclaw-tools-DrVjmaoR.js — the agent-facing cron tool (lines ~1238, ~1343, ~1419 touch payload normalization). Should enforce the same rule.

Acceptance

• cron add --name <existing> exits non-zero with the actionable error above by default.
• cron add --name <existing> --replace preserves the existing id and overwrites the other fields atomically.
• cron edit --name <existing> errs the same way if used to rename onto an existing name.
• The agent-facing cron tool returns the same error structure so agents don't trip into silent duplicates.
• Tests cover: (a) refuse on collision, (b) --replace overwrites in place, (c) disabled rows participate in the uniqueness check.

Refs

• markthebest12/openclaw-infra#1305 (where the live duplicate was found and removed).
• #28791 (cron rm by name — relies on uniqueness).