Claude Dispatch, Scheduled Tasks, and the Road to Fully Autonomous Agents

It is 10:30 PM. I am lying in bed. My phone is in my hand. I have just finished setting up the second version of my gmail-assistant agent and I am thinking: this thing should run itself. Every 8 hours. Without me.

I open the Claude app. I tap into Dispatch.

And this is the story of what happened next, why it almost worked, why it didn't quite work, and what it tells us about where AI automation is actually heading.

Click to enlarge

Me, 10:30 PM, plotting automation instead of sleeping.

First, the Agent That Started This#

Before I get to Dispatch, you need to know what I was trying to schedule. Because it matters.

The gmail-assistant agent has been running in my setup for a couple of weeks now. I wrote the first version in a previous post: a five-step pipeline that classifies 300-something unread emails into KEEP, ARCHIVE, TRASH, and FLAG buckets, then generates a draft report. It deleted 252 emails on its first run.

But I kept running it manually. Which is fine, but manual is not the same as automatic.

So I sat down (well, lay down) and built version 2.

What Changed in Gmail Assistant v2#

The v1 agent worked. V2 works better. Here are the six things I changed, and more importantly, why each change matters:

1. Extended to a 14-day window

V1 used a 7-day cutoff for bulk categories like Promotions and Social. V2 extends that to 14 days. The logic: if I have not opened a promotional email in two weeks, I am not going to open it. The cutoff moves.

2. Quick scan before bulk trash

V1 trashed Promotions and Social without any preliminary review. V2 does a 10-email quick scan of each category first, logging the senders and subjects before deleting anything. If the scan surfaces something unexpected (a confirmation email that landed in Promotions, for instance), it flags the entire batch for review instead of trashing it.

3. Content-aware classification

V1 matched on sender name and subject keywords. V2 also reads the email snippet (the first ~200 characters of the body) for classification signals. This catches the edge case where a legitimate bank notification has a subject line that pattern-matches to marketing ("Your account is ready for a special offer...").

4. Smart starred and important handling

V1 would archive or trash starred emails if they matched a rule. V2 never touches starred or Google-marked-important emails without explicit confirmation. Those markers represent intentional human decisions, and the agent should respect them.

5. Urgent notifications

V2 can generate a real notification via osascript on macOS if it finds emails matching an urgent pattern (security alerts, payment failures, emergency notices). The draft report still gets created, but urgent items also surface immediately.

6. Spam intelligence report

After the cleanup run, v2 generates a section in the draft report showing which senders appeared most frequently in the trash. Over time, this becomes a list of candidates for explicit Gmail filters, so the agent does less work on future runs.

The 14-day window and smart starred handling together solve the two most common failure modes of inbox automation: bulk-deleting something you care about, and missing promotional emails that recently arrived. The content-aware classification handles the edge cases in between.

The spam intelligence report is the feature I am most excited about over a longer time horizon. After 10 or 20 runs, that report becomes a map of exactly which senders are cluttering my inbox. I can turn those into permanent Gmail filters and progressively reduce the agent's workload. The agent gets smarter about what it does not need to look at, because it told me what to filter.

This v2 agent, freshly built, was the thing I wanted to schedule. Eight hours felt right. Morning, afternoon, evening. Inbox stays clean around the clock, no human required.

And I had a new tool to try.

Enter Dispatch#

Dispatch felt like exactly the right fit for the gmail-assistant. I have an agent that knows how to clean my inbox. I want it to run on a schedule. Dispatch is a scheduling system. The math seemed straightforward.

Click to enlarge

The math was not straightforward.

Here is what I typed into Dispatch:

"Schedule the gmail-assistant agent to run every 8 hours. It uses the GWS CLI to classify and clean my Gmail inbox. When it runs, it should use my personal GWS config at ~/.config/gws-personal."

Dispatch confirmed the task. I set the interval to 8 hours. The first scheduled run triggered while I was still awake.

And then the wheels came off.

The VM vs. Host Machine Problem#

The scheduled task ran. But it fell back to the built-in Gmail MCP instead of using the GWS CLI.

The problem: the GWS CLI is installed on my host machine (my M4 Mac Mini). The scheduled task runs in Cowork's managed VM. Those are two different environments. The VM does not have access to my local filesystem, my ~/.config/gws-personal/ directory, or the gws binary.

So when the task ran, it could not find the tool it needed. It fell back to what was available: the built-in Gmail MCP. Read-only. Useful for reading emails. Not useful for trashing 200 promotional emails.

This is what the Dispatch session looked like at that point:

Claude: The scheduled task ran successfully, but I notice the GWS CLI isn't available in this environment. I used the built-in Gmail integration instead, which gave me read access. Unfortunately, this means I could classify emails but couldn't take any actions (trash, archive, or modify).

The core issue: scheduled Dispatch tasks run in a managed cloud environment that doesn't have access to your local machine's tools or filesystems. The gws binary and your auth credentials at ~/.config/gws-personal live on your host machine, not in the Cowork VM.

That was a clear and honest explanation. I appreciated it. But I still had 200 promotional emails sitting in my inbox.

Attempt Two: Route to a Code Task#

Claude (in Dispatch) had a suggestion:

Claude: There is a workaround worth trying. Code tasks in Claude Code run on your host machine, not in the VM. If I could schedule a code task instead of running directly in Dispatch, it would have access to all your local tools. I could route the scheduled trigger to a Claude Code session on your Mac.

This was a promising idea. I had Claude Code running on my Mac Mini 24/7 anyway. If Dispatch could trigger a code task, and the code task could invoke the gmail-assistant agent with local tools, we would have achieved the goal: scheduled, automated, running with full CLI access.

I configured the routing. Set up the trigger. Waited for the next 8-hour window.

The task did not trigger a code task.

The reason, when we debugged it:

Claude: Scheduled tasks in Dispatch currently cannot spawn code tasks on your host machine. Code tasks require an active Claude Code session to be listening for incoming work, and scheduled tasks do not have a mechanism to initiate that handoff. What you are describing is essentially a push notification to your local machine from Anthropic's cloud, and that capability is not available in the current version of Dispatch.

So: scheduled tasks cannot trigger code tasks. Which means scheduled tasks cannot access host-level tools. Which means scheduled tasks, for now, are limited to what is available in the Cowork VM.

Click to enlarge

When the platform tells you no.

Option 3: The Manual Trigger That Actually Works#

After two failed attempts at true automation, Claude offered the option that actually works today:

Claude: Here is what does work right now: a manual trigger. If you open Dispatch and say "run gmail cleanup," I can route that to a code task on your host machine, which has full access to your GWS CLI and credentials. You get the benefit of not having to remember the full agent command, and the task runs in Claude Code with everything it needs. It is not scheduled, but it is fast and it works.

I had one objection:

Me: I don't want a cron job. That's a separate place to manage.

Cron was the obvious alternative. I have cron jobs running on the Mac Mini already (the OpenClaw gateway watchdog cron, specifically). I could add a new cron entry that fires a Claude Code command every 8 hours.

But here is the thing about cron: every cron job is a thing to manage. You have to remember it exists. When something breaks, you have to check the cron logs. When you change the agent, you have to update the cron entry. It is not that hard, but it is one more thread to hold.

What I actually want is for Dispatch to be that management layer. One place where I can see what is scheduled, pause it, change the interval, check the last run status. The UX of Dispatch is already there. The host-level execution capability just is not.

So that is where I landed: manual trigger via Dispatch, routes to a code task, runs with full CLI access. Not what I wanted. But it works, and it works from my phone, and I can do it lying in bed.

The OpenClaw Comparison#

Here is where I need to be honest about what I have already built versus what Dispatch promises.

OpenClaw has been running scheduled tasks since I built it. The gateway watchdog cron fires every 2 minutes to check whether the Telegram long-polling connection is alive and restart it if not. The agents respond to Telegram messages around the clock, with no human required. If I send a message from my phone at 2 AM, an agent processes it and responds.

In that sense, OpenClaw is already doing what I tried to get Dispatch to do. It just required me to:

• Set up a Mac Mini as a 24/7 server
• Configure launchd for process management
• Write the gateway watchdog cron
• Wire up Telegram bots for each agent
• Manage multiple bot tokens and API keys
• Set up Syncthing for config sync between machines
• Write the monitoring scripts to know when things break

That is a lot of infrastructure for "run tasks on a schedule."

Dispatch's promise is different: no infrastructure. No server to manage. No cron. No launchd. You describe what you want, set a schedule, and Anthropic runs it. The management layer is the Claude app.

The current limitation is that "Anthropic runs it" means "in a VM without your local tools." For most tasks, that will be fine. For tasks that need local CLIs, local auth, or local filesystem access, it is a gap.

But here is the thing: that gap is closing.

Claude (in our Dispatch session): Dispatch is gaining capabilities quickly. The current limitation around scheduled code tasks is known and being worked on. The combination of Dispatch scheduling with Claude Code execution on your host machine is exactly the pattern Anthropic is building toward. It is just not there yet in the current release.

That tracks with what I have seen. Cowork launched not long ago. Dispatch is newer still. The roadmap direction is clearly toward what I was trying to build: managed scheduling that can reach into a local Claude Code session.

Counting the Infrastructure Debt#

Here is the thing about building OpenClaw: every capability came with a maintenance cost I did not fully anticipate when I started.

The gateway watchdog cron exists because Telegram's long-polling connection drops after approximately 8 minutes of inactivity. Without the watchdog, the agents would silently stop responding and I would not know until I sent a message and waited. The cron fires every 2 minutes, checks the PID, and restarts the process if needed. It works. But it is a thing that exists, and when it breaks (the cron stops, the script has a typo, the restart fails because of a lock file), I have to debug it.

Launchd replaced the cron eventually, because launchd is more reliable on macOS for long-running processes. That migration took an afternoon. Now I have launchd config files to manage instead of crontab entries. Progress, but not elimination.

Syncthing keeps my agent configuration in sync between my Mac Mini and my laptop. It handles the claude-config folder bidirectionally. But Syncthing has its own sync status page, its own conflict resolution logic, and its own occasional surprise (the SKILL.md case-sensitivity issue I wrote about in the previous post). One more thing.

The Telegram bot tokens are secrets I have to manage. They live in ~/.claude/secrets/secrets.env, sourced from .zshrc. If I ever rotate them (or if they get accidentally exposed in a log somewhere), I have to update them in all the right places and restart the agents.

Add it up and you get a real system that does real things. But also a stack of maintenance obligations that sit in the back of your mind.

Click to enlarge

OpenClaw: powerful. Also: all of this is mine to maintain.

Dispatch's appeal is not just convenience. It is the promise of offloading that maintenance debt. Anthropic manages the scheduler, the execution environment, the uptime, the restarts. You manage the task definition. That is a fundamentally different allocation of responsibility.

What Dispatch Gets Right Today#

Even without scheduled code tasks, Dispatch is genuinely useful and worth paying attention to. Here is what it does well:

Accessibility: I set up this entire experiment from my phone, in bed. I did not need to SSH into the Mac Mini. I did not need to open a terminal. I described what I wanted in natural language and Dispatch handled the scheduling. That accessibility matters. Most cron jobs never get written because the friction is too high.

Conversational debugging: When the scheduled task failed, Claude explained exactly what happened and why. The session context was preserved across the failure. I did not have to reconstruct the problem from scratch. That conversational loop over a failed scheduled task is something you do not get from cron.

With cron, a failed job produces a log entry (if you set up logging), an exit code, and silence. You have to know to check the log. You have to know what the exit code means. You have to figure out whether the failure was transient or persistent. With Dispatch, the failure is surfaced as a conversation. Claude tells you what happened, in plain language, and offers options for what to do next.

That alone is worth something. Debugging silent automation failures is a specific kind of misery.

Natural language triggers: The manual "run gmail cleanup" trigger is genuinely useful even as a stopgap. It is faster than navigating to Claude Code, faster than typing the full agent command, and it works from anywhere.

No infrastructure to manage: Dispatch tasks live in the Claude app. I can see them, pause them, and edit them without touching a config file or SSHing into anything.

Mobile-first: This is the one that surprised me. The entire experiment in this post, from setting up the scheduled task to debugging the VM limitation to iterating on the workaround, happened on my phone. Not "technically possible on mobile, but better on desktop." Actually comfortable. The natural language interface removes the input barrier that makes mobile automation usually impractical.

Beyond Dispatch: Channels and Remote Control#

While I was working around Dispatch's VM limitations, Anthropic shipped two Claude Code features that approach the problem from a completely different angle. Instead of making Dispatch reach into your local machine, they let your local machine reach out to you.

Channels: OpenClaw Without the Infrastructure#

Remember the infrastructure stack I listed for OpenClaw? The Telegram bots, the gateway watchdog cron, the launchd process management, the bot token rotation? Channels collapse most of that into a single configuration.

Setting up a Telegram channel: create a bot via BotFather (same as OpenClaw), copy the token, restart Claude Code with the channel flag, and pair with a code. That is it. No long-polling gateway. No watchdog cron. No PID file management. Claude Code handles the connection lifecycle.

The result is functionally similar to what OpenClaw provides: you send a message from your phone via Telegram, an agent processes it on your local machine with full access to your tools and filesystem. But without the infrastructure layer I spent days building.

There is a catch. Channels require a running Claude Code session. If Claude Code is not running, the channel is not listening. OpenClaw's watchdog cron restarts the process automatically when it crashes. A Claude Code channel that goes down needs manual intervention, or your own supervision layer on top of it.

For the gmail-assistant use case, Channels give me something Dispatch could not: the ability to trigger a full agent run from my phone via Telegram, with local tool access. I send "run gmail cleanup" from Telegram, and Claude Code on my Mac Mini handles it with the GWS CLI, credentials, and everything it needs.

That is closer to what I wanted than Dispatch's manual trigger. The difference: Dispatch runs in Anthropic's cloud VM. A Telegram channel routes to my local machine.

Remote Control: The Simplest Answer#

But here is the feature that solves my problem most cleanly.

Remote Control gives you mobile access to a local Claude Code session. That is exactly the combination I was chasing with Dispatch: phone in hand, lying in bed, full local tool access.

The key difference from Dispatch: nothing runs in a cloud VM. When I use Remote Control to trigger the gmail-assistant, the agent runs on my Mac Mini. It has the GWS CLI. It has my credentials at ~/.config/gws-personal/. It has every local tool I have installed. Because it is running locally, not in Anthropic's managed environment.

The key difference from Channels: I do not need Telegram or Discord as an intermediary. I open the Claude app, connect to my running session, and type "run gmail cleanup." Same accessibility as Dispatch, same local execution as running it in the terminal. No bot tokens to manage.

If you have an always-on machine (and I do, the Mac Mini running 24/7), Remote Control is the cleanest solution for the problem I spent the first half of this post trying to solve.

How They Stack Up#

The pattern that emerges: none of these combine managed scheduling with local tool access. Dispatch can schedule but cannot reach local tools. Channels and Remote Control can reach local tools but cannot schedule autonomously. The fully automated loop I described at the start of this post (run every 8 hours, no human involvement) still requires cron or launchd for the scheduling trigger.

But the gap has narrowed considerably. The picture used to be: "Dispatch can schedule things it cannot execute, and cron can execute things it cannot schedule nicely." Now: Channels or Remote Control handle the execution layer, and the only missing piece is a managed scheduling trigger that connects to them.

Where This Is Heading#

The near-term future of this pattern is obvious and already in motion:

1. Scheduled code tasks: Channels and Remote Control already let you trigger local code tasks from your phone or via Telegram. The remaining gap is managed scheduling: the ability to say "run this every 8 hours" and have Dispatch trigger a local session automatically, whether through a Channel or Remote Control connection. When that bridge exists, the OpenClaw infrastructure advantage disappears entirely for single-machine setups.

2. Persistent agent sessions: Right now, each Dispatch task starts fresh. A persistent session model, where the agent maintains state between scheduled runs, would make agents significantly more capable. Imagine a gmail-assistant that remembers which senders it trashed last week and automatically tightens the rules.

3. Cross-machine coordination: Remote Control already enables the "phone triggers, Mac Mini executes" pattern. The next step is orchestration: Dispatch manages the schedule, routes the trigger through a Channel or Remote Control connection, and your local machine handles the execution with full tool access. The pieces exist. They just need to be wired together.

4. Audit and observability: Dispatch already shows you task history. As it matures, expect richer logs, performance metrics, and failure notifications. The "where did the scheduled task fail" debugging loop will get better.

5. Multi-agent composition: Right now, Dispatch runs a single task. The natural evolution is composition: a scheduled task that triggers a planning step, which then fans out to specialized sub-agents running in parallel. Anthropic already has the multi-agent framework in Claude Code. Wiring that into Dispatch scheduling is the obvious next step.

The timeline on any of these is speculation. But the direction is not. Every one of these capabilities already exists somewhere in Anthropic's stack. Dispatch is the surface that brings them together for people who do not want to manage infrastructure.

The Workaround I Am Actually Using#

Until scheduled code tasks exist, here is my current setup:

What I wanted: [Dispatch] → [every 8 hours] → [gmail-assistant with GWS CLI]

What I have: [Dispatch manual trigger] → [code task] → [gmail-assistant with GWS CLI]

The manual trigger takes about 5 seconds from the Claude app. I say "run gmail cleanup," Dispatch routes it to a code task on my Mac Mini, the code task invokes the gmail-assistant agent, and 3-4 minutes later I get a notification that the draft report is in my Gmail drafts.

It is not scheduled automation. But it is frictionless. And because it routes through a code task, it has full access to all my local tools, GWS credentials, and agent configurations. V2 of the agent runs exactly as intended.

The inbox cleanup still runs roughly every 8 hours. It just requires me to open the Claude app and type two words.

With Remote Control, this got even simpler. Instead of routing through Dispatch to a code task (which adds a layer of indirection), I connect directly to my Mac Mini's Claude Code session from my phone. Same two-word command, fewer moving parts, and no cloud VM in the middle.

Click to enlarge

Not automated. Not scheduled. But it works from my phone, so... it is what it is.

A Framework for Deciding Where to Run Your Agents#

After going through this experiment, I have a clearer mental model for where different types of agent automation should live. Here is how I think about it now:

Cloud-native tasks (use Dispatch): Web research, content generation, calendar planning, summarization, drafting emails, anything that does not need to touch your local machine. Dispatch handles these well, they work with the built-in MCP integrations, and you get scheduling, mobile access, and observability for free.

Local tasks, manual trigger (use Remote Control): Anything that needs a local CLI, local auth tokens, or local file access, and you are fine triggering it yourself. Gmail cleanup via GWS CLI falls here. Remote Control gives you phone access to your local session without any intermediary. If you have an always-on machine, this is the simplest option.

Local tasks, event-driven (use Channels): Same local tool requirements, but triggered by external events rather than manual action. If you want a Telegram bot that kicks off local automation, or you want to react to webhooks, Channels are the right tool. More setup than Remote Control (bot tokens, channel configuration), but you get asynchronous event handling.

Local tasks, scheduled (use cron or launchd, for now): If you need true unattended scheduling ("run every 8 hours"), you still need cron or launchd. Neither Remote Control nor Channels provide managed scheduling. Design these tasks to be portable so you can migrate to Dispatch when it gains the ability to trigger local sessions.

Multi-agent orchestration (build your own infrastructure): Complex workflows where multiple agents collaborate, hand off work, and maintain shared state. OpenClaw falls here. Dispatch, Channels, and Remote Control each handle a single session. If you need a directed graph of cooperating agents, you need to build that coordination layer yourself.

The key move is not picking one tool forever. It is building your automation so the execution layer is swappable. The agent logic (the prompt, the tool calls, the classification rules) should be the same whether it runs via Dispatch, Remote Control, Channels, cron, or manual invocation. Only the trigger and execution environment change.

Lessons Learned#

The Summary#

I built a better gmail-assistant. I tried to schedule it via Dispatch. It almost worked. The limitation (Cowork VM cannot access local tools) is real and understood. But Channels and Remote Control fill most of that gap by keeping execution local while giving you mobile access. Remote Control, in particular, is the answer if you have an always-on machine: connect from your phone, run the agent with full local tool access, done.

The one remaining gap is managed scheduling. None of these tools let you say "run this every 8 hours on my local machine" without cron or launchd handling the timer. When Dispatch can trigger a local session via Remote Control or a Channel, the loop closes entirely.

The road to fully autonomous agents runs through connecting these pieces: Dispatch's scheduling, Remote Control's local access, and Channels' event-driven architecture. The pieces exist. They just need to be wired together.

When they are, I will be lying in bed, on my phone, not even thinking about it. Because it will already be running.

Click to enlarge

The dream: one tap from the pillow, full automation. Almost there.

---

Written by Chris Johnson. The gmail-assistant agent and the CJClaudin_Mac config repo are private. All Dispatch conversation excerpts are from a real session. Emails are now being harmed regularly, via Remote Control.

Previous in series: Headless Mac Mini as an AI Server: Power Tips for Running OpenClaw 24/7