Summary
The cron tool's wake action does not accept an agentId parameter, causing all wake events to be routed to the default agent (typically main) regardless of which agent should be woken.
Current Behavior
The wake function in the cron service only accepts text and mode:
// gateway-cli source (verified in 2026.3.13)
function wake(state, opts) {
const text = opts.text.trim();
if (!text) return { ok: false };
state.deps.enqueueSystemEvent(text); // ❌ no agentId
state.deps.requestHeartbeatNow({ reason: "wake" }); // ❌ no agentId
return { ok: true };
}
Since enqueueSystemEvent receives no agentId, resolveCronAgent(undefined) falls back to resolveDefaultAgentId() → always routes to main.
Expected Behavior
The wake action should accept an optional agentId parameter (and optionally sessionKey) so that wake events can target a specific agent:
// Tool schema — add optional agentId
cron({ action: "wake", text: "CI failed, check it", mode: "now", agentId: "local-dev" })
// Implementation fix
function wake(state, opts) {
const text = opts.text.trim();
if (!text) return { ok: false };
state.deps.enqueueSystemEvent(text, { agentId: opts.agentId });
state.deps.requestHeartbeatNow({ reason: "wake", agentId: opts.agentId });
return { ok: true };
}
Contrast with Cron Job Execution
When a cron job fires normally, it correctly passes the agent ID:
// cron job execution path
state.deps.enqueueSystemEvent(text, { agentId: params.job.agentId });
// ✅ routes to the correct agent
So the infrastructure for multi-agent routing already exists — wake simply doesn't use it.
Use Case
In a multi-agent setup (e.g., main + local-dev), a monitor cron job running under local-dev wants to wake the local-dev agent's main session when CI failures are detected. Currently this is impossible via cron wake — the wake event always goes to main.
Workaround: Use sessions_send with tools.agentToAgent.enabled=true, but this requires additional configuration and is less ergonomic than a simple wake.
Environment
- OpenClaw version: 2026.3.13
- Multi-agent config with
main (default) and local-dev agents
- Both agents have separate Telegram bot accounts and bindings
Summary
The
crontool'swakeaction does not accept anagentIdparameter, causing all wake events to be routed to the default agent (typicallymain) regardless of which agent should be woken.Current Behavior
The
wakefunction in the cron service only acceptstextandmode:Since
enqueueSystemEventreceives noagentId,resolveCronAgent(undefined)falls back toresolveDefaultAgentId()→ always routes tomain.Expected Behavior
The
wakeaction should accept an optionalagentIdparameter (and optionallysessionKey) so that wake events can target a specific agent:Contrast with Cron Job Execution
When a cron job fires normally, it correctly passes the agent ID:
So the infrastructure for multi-agent routing already exists —
wakesimply doesn't use it.Use Case
In a multi-agent setup (e.g.,
main+local-dev), a monitor cron job running underlocal-devwants to wake thelocal-devagent's main session when CI failures are detected. Currently this is impossible viacron wake— the wake event always goes tomain.Workaround: Use
sessions_sendwithtools.agentToAgent.enabled=true, but this requires additional configuration and is less ergonomic than a simple wake.Environment
main(default) andlocal-devagents