Best possible solution:

Land a narrow cron-only status fix with focused tests and redacted real openclaw cron status or gateway RPC output; move the hooks-token validation change to its own reviewed PR if maintainers want it.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows current main and v2026.6.5 return state.deps.storePath from cron.status while cron data is loaded from the shared SQLite DB; I did not run the CLI in this read-only review.

Is this the best way to solve the issue?

No, not as submitted. The cron statusStorePath seam is a reasonable narrow fix, but the branch should not also carry unrelated hooks config-validation changes without separate review or maintainer acceptance.

Full review comments:

• [P2] Split the hooks-token validation out of this cron fix — src/config/validation.ts:1599-1606
  This added generic config validation is unrelated to reporting the cron SQLite path and changes the config.patch/apply validation surface for hooks.enabled setups. Because config validation is compatibility-sensitive, please remove these hooks changes from this branch or land them through a separate, explicitly reviewed PR.
  Confidence: 0.87

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 6c045c5ca3a1.

Label changes:

• add P2: This is a normal bug-fix PR for incorrect cron status output with limited blast radius, but it needs review cleanup before merge.
• add merge-risk: 🚨 compatibility: The PR adds stricter generic hooks config validation that can change existing config edit/reload behavior if merged with the cron fix.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body lists a command but does not include observed after-fix output or an artifact showing cron.status returning the SQLite path; add redacted terminal/RPC output, logs, screenshot, or recording, and a PR-body update should trigger re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P2: This is a normal bug-fix PR for incorrect cron status output with limited blast radius, but it needs review cleanup before merge.
• merge-risk: 🚨 compatibility: The PR adds stricter generic hooks config validation that can change existing config edit/reload behavior if merged with the cron fix.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body lists a command but does not include observed after-fix output or an artifact showing cron.status returning the SQLite path; add redacted terminal/RPC output, logs, screenshot, or recording, and a PR-body update should trigger re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

PR surface:

Source +16, Tests +42. Total +58 across 8 files.

What I checked:

• Current main status output uses the legacy cron store path: status() currently returns state.deps.storePath, so gateway cron.status reports the logical cron jobs path rather than the physical SQLite DB path. (src/cron/service/ops.ts:256, 6c045c5ca3a1)
• Cron persistence is SQLite-backed on current main: Cron job loading opens the shared OpenClaw state database and uses the resolved cron store path as a store key, so the active data is in SQLite even when the logical key resembles jobs.json. (src/cron/store.ts:67, 6c045c5ca3a1)
• Docs describe SQLite as authoritative cron storage: The scheduled tasks docs say job definitions, runtime state, and run history persist in the shared SQLite state database, while cron.store remains a logical key and doctor import path. Public docs: docs/automation/cron-jobs.md. (docs/automation/cron-jobs.md:43, 6c045c5ca3a1)
• PR cron commit implements the intended path override: Commit d01bd2c0d7e5e1772ca484285a0301f327152bde passes resolveOpenClawStateSqlitePath(process.env) into CronService and makes status prefer statusStorePath when present. (src/gateway/server-cron.ts:313, d01bd2c0d7e5)
• PR also includes an unrelated config-validation commit: Commit ba080f9980fe0d484e6115106ea282ab55bcdecc adds generic validation for hooks.enabled=true without hooks.token and changes hook runtime error copy; that is outside the cron status fix. (src/config/validation.ts:1599, ba080f9980fe)
• Latest release still has the reported behavior: v2026.6.5 shows cron.status returning state.deps.storePath, so the linked bug is not already fixed in the latest release. (src/cron/service/ops.ts:256, 5181e4f7c82b)

Likely related people:

• NVIDIAN: git blame points the current cron status return, SQLite-backed cron store loader, gateway cron construction, and related docs to commit 439b0582e29aec20bda6ba80af265e265420d6a8. (role: introduced current behavior; confidence: high; commits: 439b0582e29a; files: src/cron/service/ops.ts, src/cron/store.ts, src/gateway/server-cron.ts)
• Dallin Romney: Recent current-main history on src/config/validation.ts includes config warning/validation work in commit ec0f311f7fccba8e7bbf750256462a82b5bc42e0, relevant to the unrelated hooks-validation part of this PR. (role: recent config validation contributor; confidence: medium; commits: ec0f311f7fcc; files: src/config/validation.ts)
• Shubhankar Tripathy: Recent current-main history on src/config/validation.ts includes validation behavior work in commit 443115c6328ab7f0e14dcc87552153805637b326, relevant to reviewing stricter config validation. (role: recent config validation contributor; confidence: medium; commits: 443115c6328a; files: src/config/validation.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.