openclaw - 💡(How to fix) Fix [Bug]: cron tool: local llamacpp model parameter serialization corrupts JSON property names (key concatenation)

openclaw2026-05-30 20:05:33

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.

GitHub issue URL

Helpful · Quick feedback

Error Message

Gateway error response: "status": "error", "error": "invalid cron.add params: must have required property 'name'; at root: unexpected property 'namePayload'"

Root Cause

Root Cause Theory

Fix Action

Fix / Workaround

When using a local llamacpp model (qwen-27b via llama.cpp), every call to the cron tool with action: add or action: update results in corrupted JSON parameters reaching the gateway. Adjacent top-level property names are concatenated together, and nested objects get merged into flat keys.

• All cron add and cron update calls fail when using local llamacpp models • Cannot create or modify any scheduled jobs via the assistant • cron list, cron remove, cron runs work correctly (simple params) • Workaround: directly edit ~/.openclaw/cron/jobs.json (confirmed working)

Code Example

{
  "action": "add",
  "job": {
    "delivery": {"mode": "none"},
    "enabled": true,
    "namePayload": {"kind": "agentTurn", "message": "Evidence test.", "timeoutSeconds": 10},
    "scheduleKind": {"everyMs": 999999, "kind": "every"},
    "sessionTargetName": "evidence-test"
  }
}

---

{
  "status": "error",
  "tool": "cron",
  "error": "invalid cron.add params: must have required property 'name'; at root: unexpected property 'namePayload'"
}

---

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Summary

What Happened

Model & Environment

Model: local-llamacpp/qwen-27b
Host: Linux 6.19.12 (Fedora 43), x86_64
Node: v22.22.0
OpenClaw: latest (as of 2026-05-30, post-update)

Steps to reproduce

Reproduction

Configure OpenClaw with any local llamacpp model
Attempt any cron tool call via the assistant
Observe that the gateway receives mangled raw_params

Expected behavior

Intended input (what the assistant emits):

json { "action": "add", "job": { "delivery": {"mode": "none"}, "enabled": true, "name": "evidence-test", "payload": {"kind": "agentTurn", "message": "Evidence test.", "timeoutSeconds": 10}, "schedule": {"everyMs": 999999, "kind": "every"}, "sessionTarget": "isolated" } }

Actual behavior

What gateway actually receives (from `raw_params` in logs):

{
  "action": "add",
  "job": {
    "delivery": {"mode": "none"},
    "enabled": true,
    "namePayload": {"kind": "agentTurn", "message": "Evidence test.", "timeoutSeconds": 10},
    "scheduleKind": {"everyMs": 999999, "kind": "every"},
    "sessionTargetName": "evidence-test"
  }
}

Gateway error response:

{
  "status": "error",
  "tool": "cron",
  "error": "invalid cron.add params: must have required property 'name'; at root: unexpected property 'namePayload'"
}

OpenClaw version

v2026.5.27

Operating system

Fedora 44 x86_64

Install method

npm global

Model

qwen-27b

Provider / routing chain

Whatsapp -> openclaw -> llamacpp -> model

Additional provider/model setup details

Corruption Patterns Observed

Intended	Corrupted	Pattern
"name" + "payload" (separate keys)	"namePayload"	Adjacent sibling keys concatenate
"schedule" → {"kind": "every"}	"scheduleKind"	Parent key merges with first nested child key
"sessionTarget": "isolated"	"sessionTargetName": "evidence-test"	Key merges with next sibling, value gets cross-wired

Impact

Root Cause Theory

The parameter serialization layer between the llamacpp model's tool-call output and the gateway's JSON Schema validator is corrupting adjacent property names. This is specific to the local llamacpp path — not observed with remote API models. Likely in the tool-call extraction/parsing step before schema validation.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

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?

Still need to ship something?

×6

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