Problem

In a multi-agent setup, the cron tool's list action returns all jobs from every agent with no filtering by agentId. This means each agent sees the full cron job catalog (e.g., 50+ jobs across 7 agents), creating confusion and risk of cross-agent interference.

Current behavior

When any agent calls cron list (tool or CLI), the result is unfiltered:

Tool layer (openclaw-tools-BDF6gNXk.js):

case "list": return jsonResult(await callGateway("cron.list", gatewayOpts, { includeDisabled: Boolean(params.includeDisabled) }));

Server layer (server-methods-BDdu1Gof.js):

const page = await context.cron.listPage({ includeDisabled, limit, offset, query, enabled, sortBy, sortDir });

Neither layer passes or accepts an agentId parameter for filtering.

CLI:

openclaw cron list --help
# Options: --all, --expect-final, --json, --timeout, --token, --url
# No --agent filter

Impact

• Noise: Each agent sees 50+ jobs when only ~8 belong to it. Heartbeat/self-review prompts waste tokens parsing irrelevant jobs.
• Risk of accidental modification: An agent could modify/delete another agent's cron jobs (the remove action has cronSelfRemoveOnlyJobId protection for cron-triggered contexts, but update and add have no such guard).
• Prompt confusion: Agents receiving their heartbeat check see cross-agent jobs and may report incorrect status.

Environment

• OpenClaw 2026.5.2
• 7 agents (main + 6 sub-agents), ~54 cron jobs total
• Feishu channel

Suggested fix

1. Add optional agentId parameter to cron list tool action and CLI (--agent <id>)
2. Tool layer auto-fills agentId from the calling agent's session context (like cron add already does for new jobs)
3. Server-side listPage filters by agentId when provided
4. Default behavior: when called from an agent session, filter to that agent's jobs; when called from CLI without --agent, show all (backward compatible)

Workaround

Currently mitigating by adding instructions to each agent's HEARTBEAT.md:

"调用 cron list 时，只关注 agentId= 的任务。其他 agentId 的任务与本 agent 无关，必须忽略。"

This works but relies on LLM compliance and wastes context window on irrelevant jobs.

Related

• hooks.allowedAgentIds exists for hook routing but not for cron list filtering
• cron add correctly auto-sets agentId from the calling session (confirmed in source)
• The assertCronSelfRemoveScope limits remove in cron-triggered contexts but list/update remain unrestricted