Computer use in Claude Code

Use Claude Code’s computer-use tools to inspect a native app and report what happened on screen. This walkthrough uses the Mac terminal version and a small test with a visible result.

Before you start

• A Mac with a working Claude Code CLI, signed in through a claude.ai Pro or Max account. CLI computer use is a research preview; it is unavailable on Team and Enterprise plans and through third-party providers.
• An interactive Claude Code session. Computer use does not work with the non-interactive -p flag.
• A native test app you can already open yourself, with sample data and one simple control to check. For example, a preferences window whose display-size control updates a label.
• Permission to grant macOS Accessibility and Screen Recording access, and a saved copy of any project files involved.

Want to do it yourself?

Difficulty

6 out of 10

Estimated completion time

30–60 minutes

Skills you’ll need: Enable the computer-use connection, grant operating-system permissions, and compare screen evidence with a written test.

I’ll do it myselfI’d rather get help

How this helps your brand

A visible native-app test helps you check a workflow your business uses instead of relying on a verbal success claim. Capturing the actual failure gives a later repair a concrete starting point.

1. 1

   Step 1: Write a short screen test

   Open the app yourself once. Write the starting screen, the clicks to make, and the expected result. Use the exact app and control names you can see.

   For example: open Preferences, change Display size from Small to Large, and check that the preview label becomes larger. Use a setting you can put back afterward. This first task should inspect the app rather than repair its code.

2. 2

   Step 2: Enable the computer-use server

   Start Claude Code in your project, run /mcp, select computer-use, and choose Enable. The setting is saved for that project.

   If computer-use is absent, run /status to check the account and confirm that you meet the Mac, plan, sign-in, and interactive-session requirements above. The Desktop app has a separate setup; these terminal instructions do not apply to its settings.

3. 3

   Step 3: Grant the operating-system permissions

   Send the screen-test prompt below. On first use, follow the permission prompt to grant Accessibility and Screen Recording, then select Try again. Accessibility permits clicks and typing; Screen Recording permits screenshots.

   If the prompt keeps returning, quit Claude Code fully and start it again. Check that the terminal application is enabled under System Settings, Privacy & Security, Screen Recording. macOS can require restarting the requesting process after this permission changes.

   Illustrated exampleTwo permissions, two different capabilities

   First-use permission map

   Accessibility

   Click controls and type

   Screen Recording

   Capture screenshots

   1. 1Grant both permissions
   2. 2Select Try again

   Prompt returns? Check the terminal app’s Screen Recording access in macOS settings, then fully quit and restart Claude Code.

4. 4

   Step 4: Approve the app and watch the test

   Claude asks which apps it may control for this session. Review the app names and any extra access, then allow only the apps your test needs. Other visible apps are hidden while Claude controls the screen and restored afterward.

   Use a native app for this exercise. In the CLI’s current permission tiers, browsers are view-only and terminals and IDEs are click-only. Claude may choose a more specific tool when one is available.

   Tip: Press Esc anywhere, or Ctrl+C in the terminal, to stop computer use and take control back.

5. 5

   Step 5: Compare the evidence with your expectation

   Read Claude’s sequence of actions and examine the screenshot. Check the app yourself: did the label change as expected, or did Claude mistake a selected control for a successful result? Restore the test setting if necessary.

   If text is too small for Claude to read, increase its size inside the app and try again. If another session holds the computer-use lock, exit that session before retrying; finishing its task alone does not release the lock.

   For a failed check, ask for the screen and observed behavior where it failed. Keep that evidence before starting a separate repair task.

   Illustrated exampleA selected control is not proof of a working result

   Illustrated native test appExample: failed check

   ● ● ● Preferences

   Display size

   Small Large

   Preview labelSample textStill the original size

   Action completed

   Large is selected.

   Expected result

   The preview label becomes larger.

   Observed result

   The label stayed the same size.

   Report the failed result. Keep the screenshot, restore Small, and stop before a separate repair task.

Use computer use to check one flow in my native test app.

App: [exact app name]
Starting screen: [where to begin]
Actions: [numbered clicks or typing using sample data]
Expected visible result: [what should change]
Evidence wanted: [screen to capture]
Setting to restore afterward: [original value, or none]

Inspect and report only; do not edit source code or use other apps unless you explain why and I approve them. Report the actions you actually completed, the visible result, and anything blocked or unreadable. If the check fails, capture the failure and stop before attempting a repair.