Claude Code Dispatch: Turn Your Phone Into a Remote Control for Your Desktop

The moment it clicked

I was three espressos deep at a coffee shop, laptop at home on my desk, when the fix for a bug that had been haunting me all week just appeared in my head. Clear as daylight. I pulled out my phone, opened Claude Code Dispatch, and typed the fix. By the time I finished my espresso, it was done.

But rewind. Six months ago, that idea would have died in a notes app. I would have thumbed a few bullet points, told myself I would get to it later, and watched the clarity evaporate by the time I got home. We have all lived that cycle. The insight arrives at the wrong place, at the wrong time, and the cost of context switching kills it.

That is exactly the problem Claude Code Dispatch solves. You text the task from your phone. Claude Code executes it on your desktop. When it finishes, you get a push notification. Your computer did the work while you finished your espresso.

This is not hypothetical. I have been using Dispatch daily for over a month, and it has fundamentally changed how I think about when and where development happens. It has also failed on me spectacularly, more times than I would like to admit. Both of those things are true, and both matter.

Let me walk you through everything: setup, how it actually works under the hood, the tricks that make it reliable, and the honest numbers on when it falls short.

What Claude Code Dispatch actually is

At its core, Dispatch is a bridge. You pair your phone with your desktop computer via a QR code, and that opens a single persistent conversation thread that syncs across both devices. When you type something on your phone, Claude reads the instruction and decides what to do with it.

Here is the key detail most coverage misses: Claude auto-routes your tasks. If you send a development task, like "refactor the auth middleware to use JWT tokens," it goes to Claude Code, which operates in your terminal with full filesystem access. If you send a knowledge task, like "draft a product brief for the Q3 launch," it goes to Cowork, Anthropic's sandboxed computer use environment that can browse the web, write documents, and operate desktop applications.

You do not choose the routing. Claude does. And honestly, it is surprisingly good at it.

Think of it like a walkie-talkie to a capable assistant who knows which toolbox to grab. You say what needs doing. The assistant decides whether to pick up the wrench or the pen.

Setting up Dispatch

The setup process is straightforward, but there are a few prerequisites and gotchas worth knowing before you start.

Prerequisites

• A Mac. This is macOS only right now. If you are on Windows or Linux, you are locked out for the time being. There is no official timeline for cross-platform support.
• Claude Code installed on your desktop. If you have not set this up yet, check out our Claude Code tutorial for beginners for a complete walkthrough.
• The Claude mobile app on your phone (iOS or Android).
• A Max or Pro subscription. Dispatch launched for Max subscribers first, with Pro access following shortly after.

Pairing your devices

1. Open Claude Code on your desktop terminal
2. Open the Claude mobile app on your phone
3. In the mobile app, navigate to the Dispatch section
4. Your desktop will display a QR code. Scan it with your phone
5. Once paired, you will see a shared conversation thread appear on both devices

That is it. The pairing persists across sessions. You do not need to re-scan unless you explicitly unpair.

The sleep problem (and how to fix it)

Here is something that will bite you on day one if you do not prepare for it: your Mac needs to stay awake. If your computer goes to sleep while you are away, Dispatch cannot execute anything. Your task just sits in the queue, waiting, until you come home and jiggle the mouse.

This is like sending a letter to someone who is napping. The letter is perfectly written, the mailbox works fine, but nothing happens until they wake up.

The fix is a one-line terminal command that prevents your Mac from sleeping:

caffeinate -i -t 3600

That keeps your machine awake for one hour (3600 seconds). Adjust the number for longer sessions. You can also set this up as a hook in your Claude Code configuration so it activates automatically whenever you start a Dispatch session.

For a full-day session, I use:

caffeinate -i -t 28800

That is eight hours. I run it before leaving for the day, and my machine stays ready.

If you want more fine-grained control over your Claude Code setup, our 50 Claude Code tips guide covers hooks and configuration in depth.

How Dispatch works in practice

Let me walk you through a real session from last Tuesday. I was at a dentist appointment (not the most glamorous setting for a tutorial, but that is the point, development happens in the gaps now).

10:15 AM - Sitting in the waiting room, I typed on my phone: "Add rate limiting to the /api/subscribe endpoint. Use express-rate-limit, 5 requests per minute per IP, return 429 with a JSON error message."

10:16 AM - Dispatch routed this to Claude Code. On my desktop at home, Claude Code opened the project, read the existing middleware stack, installed the express-rate-limit package, wrote the middleware, added it to the endpoint, and ran the test suite.

10:23 AM - Push notification on my phone: "Task complete. Rate limiting added to /api/subscribe. All 14 tests passing. Here is a summary of changes." I tapped the notification, reviewed the diff right there in the waiting room, and sent a follow-up: "Also add it to /api/contact with the same config."

10:24 AM - Second task queued and started executing.

That is the workflow. Text, wait, review, iterate. It is asynchronous delegation, not real-time pair programming. The mental model is closer to a foreman directing workers from the office than it is to sitting at the keyboard yourself.

The single-threaded limitation

One important constraint: Dispatch is single-threaded. One task at a time. If you send a second instruction while the first is still running, it queues. It does not execute in parallel.

This means you need to think about task granularity. Instead of sending one massive instruction ("refactor the entire authentication system"), break it into discrete steps:

1. "Extract the auth logic from the route handlers into a separate middleware file"
2. "Add JWT token validation to the new auth middleware"
3. "Write integration tests for the auth middleware"
4. "Update the route handlers to use the new middleware"

Each step completes, you get a notification, you review, and you send the next one. It is slower than sitting at your desk, but you are doing it from anywhere.

The honest numbers: a 50% success rate on complex tasks

Here is where I lose most of the hype crowd, and I am fine with that.

After tracking my Dispatch sessions for a month, the success rate breaks down roughly like this:

• Simple, well-scoped tasks (add a dependency, create a utility function, write a test, fix a typo): approximately 90% success rate. These work reliably almost every time.
• Medium complexity tasks (add a new API endpoint with validation, refactor a component, implement a straightforward feature): around 70% success rate.
• Complex, multi-step tasks (architectural changes, integrating new services, anything requiring significant judgment calls): roughly 50% success rate.

That 50% number on complex tasks is not a dealbreaker. It is the honest reality of where the technology stands today. And understanding why it fails matters more than the number itself.

Why complex tasks fail

The most common failure modes I have seen:

Ambiguity kills. When your instruction has room for interpretation, Claude will interpret it, and sometimes differently from what you meant. "Make the dashboard faster" is a bad Dispatch task. "Add React.memo to the DashboardChart component and memoize the data transformation in useMemo" is a good one.

Missing context. Dispatch does not have the full mental model you carry around in your head. It reads your codebase, but it does not know about the conversation you had with your cofounder yesterday about changing the pricing model. If context matters, include it in the instruction.

Cascading decisions. When a task requires making a chain of judgment calls, each one compounds the probability of diverging from what you intended. This is where breaking tasks into smaller steps pays dividends.

Making Dispatch reliable: the CLAUDE.md advantage

The single biggest lever for improving Dispatch reliability is your CLAUDE.md file. This is the instruction file that Claude Code reads at the start of every session, and it dramatically changes how well Dispatch performs.

Without a CLAUDE.md, Dispatch is guessing at your conventions, your architecture patterns, your testing preferences. With a well-crafted CLAUDE.md, it has a playbook.

Here is what I include in mine for Dispatch-optimized projects:

# Project: api-service
 
## Architecture
- Express.js with TypeScript
- PostgreSQL via Prisma ORM
- Jest for testing
- All endpoints return { success, data, error } envelope
 
## Conventions
- Use async/await, never raw promises
- All new endpoints need input validation via Zod
- Error handling: wrap in try/catch, log with Winston, return 500 envelope
- Tests go in __tests__/ adjacent to source files
 
## File structure
- src/routes/ - Express route handlers
- src/middleware/ - Middleware functions
- src/services/ - Business logic
- src/utils/ - Shared utilities

The more specific your CLAUDE.md, the less room Claude has to improvise, and improvisation is where Dispatch gets into trouble. Think of CLAUDE.md as the briefing document you give to a contractor before they start the job. The better the brief, the less rework.

As Ethan Mollick noted in his analysis of Dispatch, the power of this feature is not just remote execution, it is asynchronous delegation. The CLAUDE.md file is what makes that delegation precise.

The file transfer gap (and the Google Drive workaround)

One frustrating limitation: you cannot attach files from your phone. If you need to send Claude a screenshot of a bug, a design mockup, or a reference document, there is no native way to do it through Dispatch.

The workaround that has worked well for me is Google Drive sync. Here is the setup:

1. Create a folder in Google Drive called "Dispatch Files"
2. Sync that folder to your desktop using Google Drive for Desktop
3. When you need to share a file, upload it from your phone to the Drive folder
4. In your Dispatch message, reference the local path: "Read the design spec at ~/Google Drive/Dispatch Files/spec.pdf"

It is not elegant. It is a workaround. But it works, and it fills a real gap until Anthropic adds native file attachment support.

Security considerations you should know

Dispatch introduces a security surface worth thinking about. Two things specifically:

Computer Use operates outside the Cowork sandbox. When Claude routes a knowledge task to Cowork and uses Computer Use (the feature that lets Claude control your mouse and keyboard), it operates outside the sandboxed environment. This means it can interact with any application on your Mac. For most tasks this is fine, but be aware of what applications are open and what data is accessible.

Your codebase is accessible remotely. By definition, Dispatch gives Claude Code access to your filesystem from a remote device. This is the whole point, but it means your phone becomes a vector. If someone gets access to your phone and the Claude app, they can send tasks to your computer. Use device-level security (Face ID, passcode) and consider unpairing when you are not actively using Dispatch.

Neither of these are reasons to avoid Dispatch. They are reasons to be intentional about how you use it.

The napkin math: is Dispatch worth it?

Let me do some rough calculations.

Before Dispatch, I estimated that I lost about 45 minutes per day to "wrong place, wrong time" friction. An idea hits while I am away from my desk, I jot down notes, I lose the context, I re-derive the solution when I get home. Or I wait until I am back at my desk to start something I could have delegated earlier.

With Dispatch, I recover maybe 20 of those 45 minutes. Not all of them, because some tasks fail and need to be redone, and some tasks are genuinely too complex to delegate asynchronously.

But 20 minutes per day, five days per week, 50 weeks per year: that is 5,000 minutes. Roughly 83 hours. Over two full work weeks of recovered productivity per year, just from being able to dispatch tasks while away from your desk.

And that calculation does not account for the compounding value of acting on ideas when they are fresh, before the mental model fades. That benefit is real but hard to quantify.

Is it worth the cost of a Max subscription just for this feature? Probably not in isolation. But if you are already using Claude Code daily, Dispatch is a multiplier on an investment you have already made.

Advanced patterns: getting more from Dispatch

After a month of daily use, here are the patterns that have made the biggest difference for me.

Batch your morning tasks

Before I leave for the gym in the morning, I write a list of 3 to 5 small tasks in my notes app. Then I dispatch them one at a time from the parking lot. By the time I am done with my workout, most of them are complete. This turns dead time into productive time.

Use preflight checks

Before sending a complex task, send a simpler one first: "Show me the current structure of the auth module and list all exported functions." Review the response. Then send the real task with confidence that you and Claude are looking at the same codebase state.

Write tasks like tickets

The more your Dispatch messages read like well-written Jira tickets, the better they perform. Include:

• What needs to happen (specific and concrete)
• Where in the codebase (file paths or module names)
• How to verify (expected test behavior or output)
• What not to do (constraints and guardrails)

A good Dispatch message: "In src/routes/users.ts, add a GET /api/users/:id endpoint that returns the user from Prisma by ID. Return 404 if not found. Add a test in src/routes/tests/users.test.ts. Do not modify the existing endpoints."

A bad Dispatch message: "Add a user lookup endpoint."

Chain tasks with verification steps

Instead of trusting a chain of three tasks blindly, insert verification tasks between them:

1. "Refactor the payment service to use the new Stripe API"
2. "Run the test suite and report any failures"
3. "Fix any failing tests from the Stripe migration"

The verification step gives you a natural checkpoint to review before proceeding.

What Dispatch is not

Let me be clear about what Dispatch is not, because the marketing framing can create unrealistic expectations.

It is not real-time pair programming. There is latency. Tasks take minutes, not seconds. You are delegating, not collaborating.

It is not a replacement for sitting at your desk. Complex architectural work, exploratory debugging, creative problem-solving: these still benefit enormously from being hands-on in your IDE. Dispatch handles the execution tasks that do not require your continuous attention.

It is not reliable enough for critical production operations. I would not use Dispatch to deploy to production or run database migrations. The 50% complex task success rate is fine for development work. It is not fine for anything where failure has immediate consequences.

It is not cross-platform. If you are not on macOS, you are waiting. This is a genuine limitation for teams with mixed operating systems.

The paradigm shift: from synchronous to asynchronous development

Here is what I think most people miss about Dispatch. The feature itself, texting tasks from your phone, is interesting but incremental. The paradigm shift is what matters.

For decades, software development has been synchronous. You sit down. You open your editor. You write code. You run it. You debug it. You are present and engaged for every step. Your output is directly proportional to your time at the keyboard.

Dispatch breaks that coupling. It introduces a model where you can think about development at one time and place, and execute development at another. The two activities are decoupled.

This is bigger than convenience. It changes the economics of an idea.

When thinking and execution are coupled, every idea has a startup cost: context switch, open the project, remember where you left off, get into flow state. That cost is usually 15 to 30 minutes. For small tasks, the startup cost exceeds the task duration, so you batch them. You wait. You let ideas accumulate. Some of them die.

When thinking and execution are decoupled, the startup cost drops to the time it takes to type a message on your phone. Maybe 30 seconds. Suddenly, small tasks become worth doing immediately. Ideas get captured as instructions, not as notes. The gap between insight and implementation shrinks from hours to minutes.

As the XDA Developers review put it, Dispatch turns your phone into a remote control for your entire workflow. But I think "remote control" undersells it. A remote control operates a device that is already playing. Dispatch lets you start things, direct things, and compose things, all from wherever you happen to be.

Where Dispatch is heading

I do not have insider information, but based on the current limitations and obvious gaps, here is what I expect to see in the next six to twelve months:

• Cross-platform support. Windows and Linux are obvious next steps. The macOS exclusivity is a pragmatic launch decision, not a philosophical one.
• Multi-threaded execution. Running parallel tasks would dramatically increase throughput for the batch-of-small-tasks workflow.
• Native file attachment. Being able to send screenshots and documents directly through Dispatch would eliminate the Google Drive workaround.
• Team Dispatch. Sending tasks not just to your own computer but to shared development environments. This is speculative, but the architecture supports it.

Getting started today

If you have made it this far and want to try Dispatch, here is the minimum viable setup:

1. Make sure you have Claude Code working on your Mac. Our beginner tutorial covers installation.
2. Install the Claude mobile app and sign in with your account
3. Pair your devices via the QR code flow
4. Run caffeinate -i -t 3600 in a separate terminal tab
5. Write a solid CLAUDE.md file for your project
6. Start with simple tasks. Build confidence before trying complex ones.

And here is my honest recommendation: give it two weeks before you form an opinion. The first few days you will over-scope tasks and get frustrated by failures. By the end of the second week, you will have calibrated your expectations and developed an intuition for what works.

Dispatch is not perfect. The 50% complex task success rate is real, macOS-only is limiting, and the sleep issue is embarrassing for a product at this level. But the core idea, decoupling when you think from when you execute, is genuinely transformative when it works.

The question is not whether async development delegation is the future. It clearly is. The question is whether the current implementation is good enough to start building that muscle memory now.

I think it is. Barely, imperfectly, frustratingly sometimes. But yes.

Try it. Break it. Tell us what you learn.