Video walkthroughs · Claude Code Club

Claude Code Computer Use: What It Can Actually Do

15 minute read · Companion guide to “Claude Code Can Now Control Your Computer”

Claude Code can now drive your desktop. It moves the mouse, types into apps, opens Chrome, records your screen, and sends files for you. The first honest reaction after using it is not excitement. It is a shrug. A test run that exported a Photoshop file to PNG and sent it over WhatsApp took about three minutes to do a job that takes a person about ten seconds. That gap is the whole story of this feature, and it points at the one setup where it stops being a toy.

Watch the full walkthrough: three real runs, the failures, and the setup

Understand the screenshot loop before you judge the speed

Computer use does not have a map of your screen. It has a camera. For every single action it takes a screenshot, sends that image off to be analyzed, decides what the next action should be, then performs it. Then it does the whole thing again for the next click.

So a task with forty small steps is forty screenshots, forty analyses, and forty decisions. The delay is not a bug in the model, it is the shape of the mechanism, and no amount of better prompting removes it. Knowing this changes how you brief it. A task with fewer, larger steps runs far better than one with many small precise ones, because every step is another chance for the loop to misread the picture.

It also explains the strange behavior you will see. In one run, instead of pasting a block of text it already had in hand, it retyped the whole post paragraph by paragraph into the browser. It was not being careless. It was choosing the action it could most reliably verify from a picture, and typing is easier to confirm visually than a clipboard operation that leaves no trace on screen.

Step 1: Turn computer use on in the desktop app

This feature is desktop app only. It does not exist in the browser version, and it is not something you enable from the terminal. Get the app from claude.com/download, install it, and sign in with your Anthropic account.

1. Open the desktop app and click your profile at the bottom of the sidebar, then open Settings.
2. There are two general tabs in the settings panel. You want the lower one, Desktop app. This is the step people miss, because the toggle is not in the first settings screen they land on.
3. Toggle computer use on and confirm the permission prompt that explains Claude will take screenshots to control your mouse and keyboard.
4. Start a chat. The first time you ask for a real action, your operating system will ask for screen and audio recording permission. Approve it in system settings under privacy and security, or nothing will work and the failure will look like the model being confused rather than a permission being off.
5. Install the Claude extension for Google Chrome. Browser steps route through it, and without it every web task stalls at the first click.

That is the full install. It takes a few minutes. Everything difficult about this feature is downstream of the setup, not inside it.

Step 2: Connect your phone, because that is where the value is

Running computer use while you are sitting at the machine is the worst version of it. It takes over your cursor, it slows your system down, and you cannot work while it works. Connecting your phone flips that. Now the machine you are not using is the one doing the work.

• Update the Claude app on both the phone and the desktop first. Version drift between the two is the most common reason the connection does not appear.
• On the phone, open the menu at the top left and choose Dispatch.
• Accept the prompt to connect your phone to your computer.
• Turn on the keep awake toggle. If your desktop sleeps, your remote session is dead, and the request will simply never come back.

From then on you send instructions from your phone as if you were texting the computer. The first practical run of this was mundane and genuinely useful: a proposal file left behind on a desktop, an important meeting coming up, and a message from the phone saying to find it and send it over Slack. It found the file and sent it. The value was not intelligence, it was reach, and reach is the thing you cannot get any other way.

The idea worth taking away: latency is only expensive when you are waiting

Nearly everyone evaluates an agent on speed. Three minutes for a ten second job reads as a failure, so the feature gets written off. That judgment is right for desk work and completely wrong for the case that matters here.

When you are on a bus, in a waiting room, or between meetings, the four minutes cost you nothing. You were not going to use them on this task anyway. The real unit of value is not time saved, it is work that would otherwise not have happened at all. The post that never got written because you were not at your desk. The file that never got sent because you were not home. Those are not efficiency gains, they are recovered outcomes, and a slow agent recovers them just as well as a fast one.

This is why the same feature can look useless and essential in the same week. Run it in front of you and it is worse than your hands. Run it while you are somewhere else and it is doing work that had no other path to getting done. Scope everything you hand it against that line.

Step 3: Move your skills where the phone can reach them

Here is the part that turns remote control from a novelty into something with an edge. Your phone has no access to the skills you have built in Claude Code. Ask the mobile app to write something and you get a generic answer, because it does not know your voice, your structure, or the research steps you spent weeks refining.

Your desktop does know all of that. Skills live in a hidden folder in your home directory, under a dot claude folder and then skills. On a Mac you reveal hidden folders in Finder with shift plus command plus period. Each skill is a markdown file, sometimes sitting alongside the supporting files it references.

To make one reachable from your phone, upload it into the desktop app's skills panel:

1. In the desktop app, open Customize, then Skills.
2. Click the plus and choose to upload a skill.
3. For a single self-contained markdown file, drag the file straight in.
4. For a skill that references other files, right click the whole folder, compress it to a zip, and drag the zip in instead. Uploading only the markdown from a multi-file skill is the quiet failure here, because it loads fine and then behaves like a much dumber version of itself.
5. Send a small test request from your phone that names the skill explicitly, and check the output sounds like your work rather than a default answer.

Naming the skill in your phone request is not optional. From a phone you cannot see what the model chose to load, so a request that says write me a post will get a generic post. A request that says use the post skill to write this in my voice gets the thing you actually built.

Worked example 1: write and publish a post without touching the machine

The real run went like this. A new Claude Code feature gets announced, the news shows up in a Reddit thread while scrolling on the move, and it is exactly the kind of thing worth posting about. Rather than dictating a post into a chat window, the request was sent to the desktop: use the post skill to write this in my voice, then go to LinkedIn and publish it. The Reddit text was pasted in underneath as source material.

The desktop wrote the post using the skill, opened Chrome, and came back with a message saying LinkedIn was open and logged in, the post was ready, and it wanted confirmation before publishing. On approval it found the post box, typed the text in paragraph by paragraph, and clicked publish. The post went live. Total human involvement: one instruction and one yes.

What that run teaches, beyond the demo:

• It paused for confirmation before the irreversible step. That is the behavior you want, and you should write your instruction to require it rather than hoping for it.
• It chose a clumsy method, retyping instead of pasting, and still got the right result. Judge these runs on the outcome, not the elegance of the path.
• The skill is what made the output usable. Without it, the same setup produces a post you would not publish, and the whole exercise collapses into typing it yourself later.

Worked example 2: build something, then have it prove the result

The harder run was a full build from the phone: make a site using a house design skill, research the product, then open the finished site in a browser, screen record it, save the recording to the desktop, and send the video over WhatsApp.

It did all of it. It built the page, asked permission to use Chrome, Finder, and QuickTime to record, then delivered a scrolling video of the result to a phone. The catch is real and worth stating plainly: it pulled no actual product imagery, so the page was built without the photos that would make it convincing. The design system held. The content did not.

The transferable move is the proof step, not the build. Asking for a screen recording turns a remote task from something you have to trust into something you can check in fifteen seconds on a phone. Any remote request that produces a visual result should end with an instruction to capture that result and send it to you. Without it you are approving work you cannot see.

The imagery gap also shows the boundary clearly. Computer use drives an interface. It does not go and fetch things from the web unless you give it a tool that does. Connect a scraping tool for that job and the same request can pull real images and brand details instead of inventing around the hole.

Decide what to trust it with, and what to keep away from it

This is the fork that decides whether you keep the feature enabled after week one. The sorting rule is not difficulty, it is consequence. Ask what happens if it misreads one screenshot at the worst possible moment, and let that answer place the task.

Hand it errands that are reversible and self-evident:

• Find a file on the desktop and send it to a person or a channel you named.
• Run a skill you built and put the result somewhere you can review it.
• Open a thing, record it, and send you the recording.
• Publish a draft you have already read, after an explicit confirmation.

Keep it away from anything where a wrong click is expensive or invisible:

• Banking, payment dashboards, invoicing, and anything that moves money.
• Email you have not read. Sending on your behalf is a category of mistake you cannot take back.
• Deleting, archiving, or bulk editing anything. Destructive operations look identical to safe ones through a screenshot.
• Admin panels, hosting consoles, and DNS. A misread click here breaks something you will not notice until it is live.
• Any account where you are not the only person affected by the mistake.

Take the privacy cost seriously, because it is constant

Computer use works by photographing your screen and sending those images away to be analyzed. Not once at the start. Continuously, for every step, for the whole run. That is not a hidden risk, it is the stated mechanism, and it deserves a habit rather than a worry.

The rule is simple. If something on your screen should not leave your machine, it should not be on your screen while this runs. Client contracts, private messages, medical or financial documents, credentials sitting in a password manager window, another person's data you were trusted with. None of that is malice, it is just what happens when a camera is pointed at a desk you did not tidy.

• Close everything unrelated before you leave the desk, especially messaging apps that show previews.
• Run remote sessions from a clean desktop or a separate user account if your work involves other people's confidential material.
• Never leave a credential manager unlocked and visible while a session can run.
• Approve app permissions one at a time when it asks, rather than granting everything up front. The prompts are your last checkpoint.

The failure modes, named so you recognize them fast

These are the ones that show up in real use rather than in a demo. Each has a tell, so you can diagnose from a phone instead of guessing until you get home.

• It stalls with no message. Usually the desktop went to sleep. The keep awake toggle is off, or the machine lost power. Nothing recovers this remotely.
• It hovers on a page and does nothing useful. Usually a login wall or a two-factor prompt it cannot pass. It will often describe the screen rather than say it is blocked.
• It cannot decide how to interact. Arrow keys or the mouse, this field or that one. The tell is repeated near-identical actions. Break the request into fewer, larger steps and name the target app explicitly.
• The output is generic. The skill was not loaded, or the uploaded copy is missing its supporting files. Name the skill in the request and re-test it locally.
• It builds something with holes in it, like a page with no images. It only has the tools you gave it. Missing content is almost always a missing tool, not a reasoning failure.
• It does the wrong reversible thing correctly. Your instruction was ambiguous. Written requests from a phone are shorter than you think, and short requests get filled in with assumptions.

Run your first useful remote task in a single sitting

The shortest honest path from reading this to having something real working. Give it about an hour, most of which is the test loop rather than the setup.

1. Install the desktop app, enable computer use in the Desktop app settings tab, approve screen recording in your system privacy settings, and install the Chrome extension.
2. Give it one throwaway local task while you watch, so you learn the pace and see the approval prompts before they matter. Exporting a file and sending it somewhere is enough.
3. Update both apps, open Dispatch on your phone, connect it to the desktop, and turn on keep awake.
4. Send one trivial request from your phone in the same room, something like find a named file on the desktop and send it to me. Confirm it comes back before you trust it from anywhere else.
5. Upload one skill you already use, zipping the folder if it references other files, and send a phone request that names that skill by name.
6. Add a proof step to that request. Have it show you the result, or record it, before it does anything final.
7. Write your own two lists, the errands you will hand over and the accounts that are off limits, and keep them somewhere you will see them on your phone.
8. Leave the house and run one real request. That is the only test that tells you whether this belongs in your workflow.

Do that once and you will know within a day whether this is a permanent part of how you work or a feature you keep off until it gets faster. Both answers are legitimate right now.

Where this actually stands today

The honest verdict after a week of real use: it is slow, it hesitates, it often does not know whether to use the keyboard or the mouse, and it has to analyze every frame to make the smallest decision. As a replacement for your hands it is not close.

But the direction is obvious. The screenshot loop gets cheaper and faster over time, and the moment it does, every task on the too slow list moves onto the worth it list without you changing anything about your setup. The people who benefit first are the ones who already built the skills the agent will run, because that is the part that does not arrive with a software update.

So treat this period as preparation rather than payoff. Get the setup working, learn the scoping rules while the stakes are low, and build the skills that make a one line request from a phone come back as something you would have made yourself. The remote control is the easy half. The thing worth controlling is what you spend the wait building.

Read this online at claudecodeclub.ai