docs/ncl-tasks-migration.md
ncl tasks migrationIf an agent mentions schedule_task, list_tasks, update_task, cancel_task, pause_task, or resume_task, it is using the old scheduling MCP surface.
A subtler symptom of a stale container image: the agent reports a task as scheduled, but ncl tasks list shows nothing and the host log has Unknown system action — the old image's schedule_task call is acknowledged in-container and then dropped by the new host. The fix below (rebuild + restart) resolves it.
Scheduling moved to ncl tasks. New tasks are stored in a per-agent-group system session and run there, so a scheduled task does not wake an existing chat session. When it fires, the agent must choose the delivery destination explicitly.
Rebuild and restart agent containers so they load the updated MCP tool list and instructions:
./container/build.sh
launchctl kickstart -k gui/$(id -u)/com.nanoclaw
On Linux, restart with systemctl --user restart nanoclaw.
Use:
ncl tasks list
ncl tasks create --group <agent_group_id> --prompt "..." --process-after "2026-01-15T09:00:00" --recurrence "0 9 * * *"
ncl tasks update --id <series_id> --prompt "..."
ncl tasks cancel --id <series_id>
Run ncl tasks list. New task rows should show a system session_id, not the chat session that requested the task.
Tasks created through the old MCP tools live in the chat session that created them, not in a per-series system session. They are unaffected by this update: they keep firing and delivering exactly as before. Two things to know:
ncl tasks list (group scope) shows only its group's task rows; from the host, unscoped ncl tasks list enumerates everything, and --session <id> narrows to one session — that is how you find and manage legacy rows (ncl tasks cancel --session <chat_session_id> --all to clear a chat session's tasks).messages_in status enum now includes cancelled (cancel marks the row and clears its recurrence rather than deleting it). Custom code that exhaustively switches on task status needs the new arm.Order matters:
ncl tasks (ncl tasks list / delete) — they live in per-series system sessions the old code doesn't know about.Reverting before the task sessions are collected leaves system sessions behind that the old findSessionByAgentGroup (which has no system-session exclusion) can resolve as the group's session — mis-routing agent-to-agent messages into a dead task thread.