Summary

Add single-job cron inspection by id so callers can fetch one cron job directly instead of listing and filtering the full job set.

Problem to solve

openclaw cron currently only exposes detailed cron job inspection through cron list --json, so callers must fetch and filter the entire cron job set even when they already know the target job id.

This is inefficient for agent-driven and scripted workflows. In my case, an OpenClaw agent needs to inspect one cron job's full definition, but today it has to call cron list --json and consume the whole job list first. That increases payload size and token cost unnecessarily.

It is also inconsistent with the existing cron command surface, where cron jobs are already treated as id-addressable resources for mutation:

• openclaw cron edit <id>
• openclaw cron run <id>
• openclaw cron rm <id>

The read path is the missing piece.

Proposed solution

Add a single-job read path for cron jobs.

Desired behavior:

• CLI: openclaw cron get <id>
• Gateway RPC: cron.get
• Return the full stored cron job definition for the requested id
• Return a clean error when the id does not exist

Scope boundary:

• no change to cron scheduling
• no change to cron execution
• no change to delivery behavior
• no change to existing cron list behavior

This should be a minimal additive read API for an already id-addressable cron resource.

Alternatives considered

• Continue using openclaw cron list --json and filter client-side. This is weaker because it forces full-list retrieval even when the caller already knows the id, which is wasteful for agents and scripts.

• Add an --id filter to cron list. This is weaker because it overloads collection-listing semantics instead of exposing a proper single-resource read path. cron.get is a cleaner match for the existing id-based cron operations.

Impact

Affected: OpenClaw agents, scripted workflows, and operators who need to inspect one cron job in detail Severity: Low to medium Frequency: Repeated whenever single-job inspection is needed Consequence: unnecessary payload expansion, avoidable token usage, and extra client-side filtering logic

For agent-driven workflows, this is especially costly because the current workaround requires sending the full cron job set through the model path even when only one job is relevant.

Evidence/examples

Current workaround:

• call openclaw cron list --json
• filter the returned job array client-side by id

Example use case: an OpenClaw agent wants to inspect one cron job's message, delivery mode, schedule, or session target, but currently has no direct get by id path.

The existing command surface already supports id-based mutation:

• openclaw cron edit <id>
• openclaw cron run <id>
• openclaw cron rm <id>

That suggests single-job inspection is the missing complementary read capability.

Additional information

I already implemented and tested a minimal additive version locally with:

• openclaw cron get <id>
• cron.get gateway RPC

The change is intentionally small and limited to single-job inspection.

Local validation:

• targeted CLI/protocol/server cron tests passed
• pnpm check passed
• full pnpm test in this checkout was not fully green, but the observed failures were outside the cron surface