Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

A running isolated cron job appears in openclaw tasks list --runtime cron --status running, but attempting to cancel it with openclaw tasks cancel <taskId> fails with:

Task runtime does not support cancellation yet.

This makes it hard to stop a runaway cron job, especially when the job is consuming a large context/token budget or an MCP server has become unhealthy.

Steps to reproduce

I have a recurring cron job that uses a Gmail MCP server. Sometimes the job appears to hit token/context bloat even though the job prompt tells it not to fetch message bodies.

When this happens:

• The cron run keeps running.
• Sending /stop from the Web UI session does not stop it.
• The run appears in the task ledger.
• openclaw tasks cancel <taskId> returns Task runtime does not support cancellation yet.
• After the failed/stuck run, the Gmail MCP tools may no longer be visible/usable until I restart the Gateway.

openclaw tasks list --runtime cron --status running
openclaw tasks list --runtime cron --status running --json
openclaw tasks cancel
openclaw cron runs --id --limit 10

Expected behavior

A running cron task shown by openclaw tasks list should either:

1. be cancellable with openclaw tasks cancel <taskId>, aborting the underlying cron agent run, or
2. clearly report that cron tasks are not cancellable and point to the recommended operator escape hatch.

Ideally, the Web UI should also expose a reliable stop/cancel action for active cron/background runs.

Actual behavior

openclaw tasks cancel <taskId> fails with:

Task runtime does not support cancellation yet.

OpenClaw version

2026.6.1

Operating system

Ubuntu

Install method

npm

Model

qwn3.6

Provider / routing chain

lmstudio

Additional provider/model setup details

Local

Logs, screenshots, and evidence

`Task runtime does not support cancellation yet.`

Impact and severity

A runaway cron job can continue consuming tokens/context until timeout or Gateway restart. The operator cannot reliably stop it from the Web UI or task CLI.

After stopping/restarting from this state, the Gmail MCP server sometimes appears unhealthy: tools are no longer visible until Gateway is restarted. I’m not sure whether this is a separate MCP cleanup issue or a consequence of the stuck cron run.

Additional information

No response