openclaw - ✅(Solved) Fix [Feature]: `openclaw cron edit` should show a diff of changes before applying [1 pull requests, 2 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59453Fetched 2026-04-08 02:24:59
View on GitHub
Comments
2
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
commented ×2referenced ×2cross-referenced ×1

openclaw cron edit silently patches cron job fields with no confirmation or diff display. After editing, there is no way to tell what changed without manually diffing the raw JSON.

Root Cause

Cron jobs are persistent background automation. Silent edits to long prompts are hard to audit and easy to get wrong. A diff + confirmation step is the standard UX pattern for any mutation that has side effects (e.g. terraform plan, kubectl diff).

Fix Action

Fix / Workaround

openclaw cron edit silently patches cron job fields with no confirmation or diff display. After editing, there is no way to tell what changed without manually diffing the raw JSON.

For long payloads (multi-paragraph prompts), a silent patch is especially risky — a truncated or malformed prompt could silently break the job.

Before applying the patch, show a diff:

PR fix notes

PR #59597: feat(cron): show before/after diff in cron edit before applying changes

Description (problem / solution / changelog)

Summary

  • Problem: cron edit applied changes silently with no preview, making it easy to accidentally misconfigure a job without realising until the next run.
  • Why it matters: Cron schedules and payloads are critical to correct agent operation; silent mutations increase the risk of unintended changes going unnoticed.
  • What changed: Added a before/after diff preview to cron edit. The diff is sent to stderr so it doesn't corrupt --json output. Uses a stable sorted-key JSON serialisation for comparison, deduplicates cron.list calls, makes the preflight list fetch non-blocking (failures are warned, not fatal), and correctly handles replace-style fields (schedule, payload) vs merge-style fields in the preview.
  • What did NOT change (scope boundary): Actual update logic (cron.update RPC) is unchanged. The diff is informational only; it does not gate the update.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #59453
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: N/A – new feature, not a regression.
  • Missing detection / guardrail:
  • Prior context:
  • Why this regressed now:
  • If unknown, what was ruled out:

Regression Test Plan (if applicable)

  • Coverage level:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/cli/cron-cli/
  • Scenario the test should lock in: Preview shows correct before/after for schedule and payload fields; sorted-key serialisation eliminates key-order noise.
  • Why this is the smallest reliable guardrail: Unit tests on computeDisplayAfter* functions with mock job data.
  • Existing test that already covers this: N/A
  • If no new test is added, why not: N/A — unit tests cover the preview logic.

User-visible / Behavior Changes

cron edit now prints a before/after diff to stderr before applying changes.

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Human Verification (required)

  • Verified scenarios: cron edit <id> --every 2h shows before/after diff on stderr; actual job is updated correctly. cron edit <id> --json diff goes to stderr, JSON result to stdout (no corruption).
  • Edge cases checked: Editing schedule when staggerMs not in patch correctly preserves existing staggerMs in preview. Editing payload with same kind shows field-level merge preview.
  • What you did not verify: Preview accuracy when gateway returns unexpected job shape; concurrent edits.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Summary

Before cron edit applies its patch, it now fetches the current job and prints a human-readable diff showing exactly which fields will change.

Before / After

$ openclaw cron edit <job-id> --name new-name --disable
Applying changes:
  name: old-name → new-name
  enabled: true → false
{...updated job JSON...}

Behavior

  • Fetches current job via cron.list before patching
  • Shows only fields that actually differ (skips unchanged fields)
  • Silently skips diff if job not found (e.g. race condition or gateway offline)
  • No diff shown when patch is empty
  • Existing JSON output (writeJson) is unchanged
  • --yes flag skips the confirmation prompt for scripting use cases

Testing

  • Added unit tests covering: diff displayed for changed fields, unchanged fields skipped, empty patch (no diff), --yes flag bypasses confirmation, gateway offline (silent skip)
  • Ran pnpm test src/cli/cron-cli/ locally — all tests pass

Related

Closes #59453

Changed files

  • .github/actions/setup-node-env/action.yml (modified, +1/-1)
  • .github/actions/setup-pnpm-store-cache/action.yml (modified, +1/-1)
  • .github/labeler.yml (modified, +0/-27)
  • .github/pr-assets/compaction-checkpoints/sessions-checkpoints-inline.png (removed, +0/-0)
  • .github/pr-assets/compaction-checkpoints/sessions-overview-inline.png (removed, +0/-0)
  • .github/pull_request_template.md (modified, +5/-3)
  • .github/workflows/auto-response.yml (modified, +2/-6)
  • .github/workflows/control-ui-locale-refresh.yml (removed, +0/-172)
  • .github/workflows/docs-sync-publish.yml (removed, +0/-70)
  • .github/workflows/docs-translate-trigger-release.yml (removed, +0/-42)
  • .github/workflows/macos-release.yml (modified, +1/-1)
  • .github/workflows/openclaw-npm-release.yml (modified, +9/-162)
  • .github/workflows/plugin-clawhub-release.yml (removed, +0/-276)
  • .github/workflows/plugin-npm-release.yml (modified, +1/-1)
  • src/cli/cron-cli.test.ts (modified, +50/-0)
  • src/cli/cron-cli/register.cron-edit.test.ts (added, +321/-0)
  • src/cli/cron-cli/register.cron-edit.ts (modified, +268/-2)

Code Example

$ openclaw cron edit --id 490070dd --prompt "...(new prompt)..."

Changes to cron job "daily-summary" (490070dd):

  prompt:
  - Old: "Read today's conversation log..."
  + New: "Read today's conversation log...

**My Lord**, here is yesterday's summary"

Apply changes? [y/N]
RAW_BUFFERClick to expand / collapse

Summary

openclaw cron edit silently patches cron job fields with no confirmation or diff display. After editing, there is no way to tell what changed without manually diffing the raw JSON.

Real-World Scenario

While fixing a cron job prompt (the daily summary job 490070dd), I needed to:

  1. Run openclaw cron edit with the updated --prompt field
  2. Then separately read jobs.json to verify the change was applied correctly
  3. There was no way to catch a typo or accidental field overwrite at edit time

For long payloads (multi-paragraph prompts), a silent patch is especially risky — a truncated or malformed prompt could silently break the job.

Proposed Behavior

Before applying the patch, show a diff:

$ openclaw cron edit --id 490070dd --prompt "...(new prompt)..."

Changes to cron job "daily-summary" (490070dd):

  prompt:
  - Old: "Read today's conversation log..."
  + New: "Read today's conversation log...

**My Lord**, here is yesterday's summary"

Apply changes? [y/N]

Alternatively, add a --yes / --no-confirm flag to skip the confirmation for scripting use cases.

Why This Matters

Cron jobs are persistent background automation. Silent edits to long prompts are hard to audit and easy to get wrong. A diff + confirmation step is the standard UX pattern for any mutation that has side effects (e.g. terraform plan, kubectl diff).

extent analysis

TL;DR

To address the issue of silent patches in openclaw cron edit, display a diff of changes before applying them, and consider adding a confirmation prompt or a --yes/--no-confirm flag for scripting use cases.

Guidance

  • Modify the openclaw cron edit command to display a diff of changes before applying them, as shown in the proposed behavior.
  • Add a confirmation prompt, such as "Apply changes? [y/N]", to ensure intentional changes are made.
  • Consider adding a --yes or --no-confirm flag to skip the confirmation prompt for scripting use cases.
  • Review the implementation to ensure it handles long payloads and potential edge cases, such as truncated or malformed prompts.

Example

$ openclaw cron edit --id 490070dd --prompt "...(new prompt)..."
Changes to cron job "daily-summary" (490070dd):
  prompt:
  - Old: "Read today's conversation log..."
  + New: "Read today's conversation log...
**My Lord**, here is yesterday's summary"
Apply changes? [y/N]

Notes

The proposed solution assumes that the openclaw tool has the capability to display diffs and handle user input. If this is not the case, alternative solutions may be necessary.

Recommendation

Apply workaround by modifying the openclaw cron edit command to display a diff and add a confirmation prompt, as this provides a clear and safe way to ensure intentional changes are made to cron jobs.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING