OpenClaw's new /tasks feature changes how you manage your agent

By Linas Valiukas · April 4, 2026

If you've ever kicked off a long-running job in OpenClaw - a cron task, a subagent pipeline, a background ACP run - you know the feeling. You send the command. It disappears into the void. You wait. You check logs. You wonder if it crashed or if it's just slow. You poke around the CLI. Nothing helpful comes back.

That was OpenClaw's background task experience until last week. v2026.4.1 shipped /tasks - a slash command you can type in any chat session to see what your agent is doing behind the scenes. It sounds small. It's not.

What /tasks actually does

Type /tasks in any chat - WhatsApp, Telegram, Discord, the web UI, wherever your OpenClaw instance lives. You get a board showing every background task linked to that conversation: what's running, what finished, what failed, and how long each one took.

If there are no tasks tied to the current session, it falls back to a summary of everything running across your whole agent. Active task count, failures, runtime breakdown by type.

Under the hood, this is the user-facing surface of a much bigger rewrite. Starting with v2026.3.31, the OpenClaw team replaced the old fragmented task management with a unified SQLite-backed ledger. Every background operation - ACP runs, subagent spawns, cron executions, CLI commands - now gets tracked in one place. /tasks is just the first way to peek into that ledger from inside a conversation.

Why this matters more than it sounds

Before this system, background tasks in OpenClaw were a mess. Not broken, exactly. Just disconnected from each other in ways that made your life harder.

Cron jobs, subagents, ACP sessions, and CLI background commands each had their own lifecycle. If a cron job failed at 3am, you'd find out when you checked the logs the next morning - or you wouldn't find out at all. Subtask results couldn't trace back to the parent session that spawned them. If the gateway crashed mid-task, that work was just gone. Orphaned processes piled up quietly. Security researcher Alexander Feick flagged the core problem: OpenClaw lacked "a control plane that can express fine-grained trust boundaries." The new task ledger is the first step toward one.

The new system gives you one answer to "what's happening right now?" That's something OpenClaw has never had.

The CLI side

The chat command is the headline feature. But if you're SSH'd into your server, there's a full CLI layer too:

• openclaw tasks list - shows all tasks, filterable by runtime type (acp, subagent, cron, cli) and status
• openclaw tasks show <task-id> - full details on a specific task
• openclaw tasks cancel <task-id> - kill a running task
• openclaw tasks audit - health check that flags stuck, orphaned, or lost tasks

There's also openclaw flows list for multi-task workflows, and openclaw tasks notify to control whether a task pings you on every state change, only when it finishes, or not at all.

How task lifecycle works

Every background operation flows through the same states: queued, running, then one of five terminal states - succeeded, failed, timed out, cancelled, or lost.

That last one is new. "Lost" means the backing session disappeared - the gateway crashed, the connection dropped, something went sideways - and the task never reported a result. There's a 5-minute grace period before a task gets marked lost. Brief blips shouldn't trigger it, but a hard crash will.

Completed tasks stick around for 7 days, then get automatically pruned by a sweeper that runs every 60 seconds. So you've got a week to go back and check what happened. After that, it's gone.

What to watch out for

It's a genuine improvement. It's also v1 of a complex system, and there are rough edges.

• No crash recovery (yet). If your gateway dies mid-task, that task won't resume. v2026.4.2 added "durable task flows" with resume-from-interruption, but only for managed-mode flows - not for every task type. Regular cron and CLI tasks are still fire-and-forget.
• The 5-minute lost threshold can misfire. A temporary network hiccup longer than five minutes will mark your task as lost even if the underlying process is still running. You'd need to check manually.
• No daemon mode. OpenClaw still doesn't have a --daemon flag. You need pm2, systemd, or Docker to keep the gateway alive. If it stops, your tasks stop, and nothing restarts them automatically.
• The webhook endpoint ships without auth. If you're using webhooks to trigger tasks, you'll need to add authentication yourself via a reverse proxy. By default, anyone who finds the endpoint can fire off tasks on your agent.

That last point is worth emphasizing. We've written about 30,000+ exposed OpenClaw instances and the nine CVEs in four days. An unauthenticated webhook endpoint is one more surface for someone to poke at.

What came right after: v2026.4.2

The /tasks feature landed on April 1. Two days later, v2026.4.2 shipped with durable task flow orchestration - the ability for multi-step pipelines to survive a gateway restart and pick up where they left off instead of starting over.

This is the pattern we keep seeing. A feature ships with known limitations, and a patch follows within days. If you're self-hosting, the question isn't whether the feature is good - it's whether you can keep up with the release pace to actually get the fixes.

Who this is actually for

If you're running a simple OpenClaw setup - one agent, a few cron jobs, maybe Telegram integration - /tasks is nice but not life-changing. You already knew what your agent was doing because there wasn't much to keep track of.

Where it gets interesting is multi-agent setups. Subagents spawning other subagents. Cron jobs that trigger ACP sessions that trigger CLI commands. If you've built anything like that, you've been flying blind until now. The unified task ledger and /tasks board give you a way to actually see what's happening across all of it.

The 36kr article about this release called it a "task brain" for OpenClaw - an operating-system-level control panel. That's aspirational. Right now it's more like a task list with good visibility. But the foundation is there, and the SQLite-backed ledger is the kind of infrastructure that makes future features possible.

Or skip the ops work

The /tasks feature solves a real problem. But it solves it by giving you more tools to manage your own infrastructure. More commands to learn, more states to monitor, more webhook endpoints to secure, more updates to install before the next batch of fixes arrives.

TryOpenClaw handles all of this for $39/month. Your background tasks run on managed infrastructure with monitoring, automatic restarts, and security already configured. No pm2, no systemd, no exposed webhooks. You get the useful parts of OpenClaw without becoming its sysadmin.