openclaw - 💡(How to fix) Fix cron run-log: hard-coded 2000-char summary truncation makes long agent outputs unreadable [1 participants]

Problem

pickSummaryFromOutput in src/cron/isolated-agent/helpers.ts hard-codes the summary length cap at 2000 chars before writing each entry to cron/runs/<jobId>.jsonl:

function pickSummaryFromOutput(text) {
    const clean = (text ?? "").trim();
    if (!clean) return;
    const limit = 2e3;
    return clean.length > limit
      ? `${truncateUtf16Safe(clean, limit)}…`
      : clean;
}

(file in published bundle: dist/helpers-C968UOoJ.js, lines 18–23)

For agents whose deliverable IS the assistant text — e.g. a daily news-digest cron that produces 6–8 markdown briefings of ~400 chars each — this means the run-log is silently truncated mid-item. The actual delivered message (Feishu/Slack/etc.) is fine, but openclaw cron runs --id <id> only ever shows the first ~5 items, with the trailing ….

This makes it hard to:

• audit what was actually sent on a past run,
• diagnose "did the agent produce a complete output?" vs "did delivery drop something?",
• decide whether to manually re-trigger (which I just did, then duplicated 3 messages to a chat group because the truncated log looked incomplete).

Reproduce

1. Configure a cron job whose agent reply is > 2000 chars (e.g. a markdown digest with 6+ sections).
2. Let it run, then openclaw cron runs --id <jobId>.
3. The summary field in every entry is exactly 2001 chars (2000 + "…"), regardless of the real output length.

OpenClaw 2026.4.14 (323493f), Windows 11.

Suggested fix

Make the limit configurable under the existing cron.runLog config group (already has maxBytes and keepLines):

"cron": {
  "runLog": {
    "maxBytes": "2mb",
    "keepLines": 2000,
    "maxSummaryChars": 20000   // new — default e.g. 8000 or 20000
  }
}

Plumb it through appendCronRunLog → pickSummaryFromOutput. The 2000-char default predates the prune-by-maxBytes/keepLines logic that already bounds total file size, so per-entry truncation is now double protection — the bound on total bytes is what actually matters for disk usage.

If keeping a hard default is preferred, even bumping it to ~20000 chars (roughly one Slack/Feishu max-message worth) would cover almost every real cron summary without meaningful disk impact (maxBytes already caps the file at 2 MB).

Happy to send a PR if the direction is agreed.