DEV Community: Auten

Your computer-use agent's clicks do nothing in admin windows on Windows

Auten — Tue, 27 Oct 2026 06:57:59 +0000

Your agent drives Windows fine all day. Then it reaches Task Manager, an elevated terminal, Registry Editor or an installer, and everything stops working at once: the element list comes back empty, the click tool returns "ok", and nothing on screen moves. The screenshot still shows the window perfectly.

That is not the model and usually not a bug in your MCP server. It is User Interface Privilege Isolation (UIPI), and like most Windows security boundaries it fails silently.

What UIPI blocks

Every Windows process runs at an integrity level. A normal process, including one started by an account that is in the Administrators group, runs at Medium: UAC filters the admin rights out of the token. Anything started with "Run as administrator" runs at High.

UIPI stops a lower-integrity process from driving a higher-integrity one:

Synthetic input. SendInput into a higher-integrity window is dropped. Microsoft's own docs for SendInput say that neither the return value nor GetLastError tells you the failure was caused by UIPI. Your tool reports success because, as far as the API is concerned, it was one.
Window messages. PostMessage / SendMessage of most messages to an elevated window are blocked too, so the "click via message" fallback many tools use fails the same way.
UI Automation. A Medium client cannot read the UI tree of an elevated app, so element discovery returns nothing. This is the symptom that usually shows up first.

What still works: capturing the screen. A Medium process can take a screenshot of an elevated window, which is why the agent can describe the window it cannot touch.

A public bug report on another open-source agent shows the exact pattern: screenshots fine, 0 elements, click returns ok: true with no effect, agent at Medium, target elevated. It is not specific to any one tool. Every desktop agent that does not run elevated hits it.

Check it in thirty seconds

The agent side. In the terminal or app that launches your agent:

   whoami /groups | findstr /i "Mandatory"

Medium Mandatory Level = normal. High Mandatory Level = elevated.

The target side. Task Manager > Details, right-click a column header > Select columns > Elevated. Any target with "Yes" there is out of reach for a Medium agent.

If the agent is Medium and the target is elevated, you have found the problem.

Fixes, in the order we would try them

Don't elevate the target. Most of the time it does not need it. The usual culprit is a terminal or IDE that was set to always run as administrator (Properties > Compatibility, or a shortcut's Advanced settings). Turn that off and the agent can drive it again.
Run the agent host elevated, on purpose. Start the terminal or MCP client with "Run as administrator" so the agent runs at High too. Be honest with yourself about what this means: everything the agent does now runs with admin rights. Do it for the one task that needs it, not as your default.
uiAccess, if you ship the tool. An app whose manifest sets uiAccess="true" may drive higher-integrity windows, but only if it is signed with a trusted certificate and installed in a protected location such as Program Files. That is how screen readers do it. It is not something you switch on for a script in your home folder.

What none of these fix: UAC prompts. The "Do you want to allow this app to make changes" dialog appears on the secure desktop, which no ordinary process can see or click. That is by design. An agent should stop and ask you there, not try to work around it.

A short pre-flight before you blame the model

Screenshot fine, element list empty, clicks "ok" but ignored -> check elevation first.
Agent at Medium, target "Elevated: Yes" -> un-elevate the target, or elevate the agent for that one task.
A UAC prompt is up -> the agent cannot answer it. You do.

Why we care

We build Auten, an MCP server that gives Claude Code, Codex, Cursor or any MCP client hands on a real screen: your computer (Mac, Windows, Linux) and your Android phone (beta). On Windows it installs per user without admin rights, so by default it runs at Medium integrity and this rule applies to it exactly like to every other non-elevated tool. Setup is at auten.ai/mcp.

If you have hit a Windows case where an agent sees a window but cannot touch it and elevation was not the cause, describe it in the comments. We collect these.

Your AI agent can't see your Android phone: adb 'unauthorized', 'offline' and 5 other causes

Auten — Fri, 23 Oct 2026 06:15:47 +0000

Every tool that lets an AI agent drive an Android phone over USB sits on the same thing: adb. When the agent says "no device found", the agent is almost never the problem. The phone and the computer have not agreed to talk yet.

Run this first:

adb devices -l

Whatever it prints tells you which of the causes below you have.

1. `unauthorized`: the phone never approved this computer

The phone lists the computer's RSA key as untrusted. Usually the "Allow USB debugging?" prompt was dismissed, or it appeared while the screen was locked and you never saw it.

Fix:

Unlock the phone, unplug, plug back in, and tap Allow with "Always allow from this computer" ticked.
No prompt at all? In Developer options tap "Revoke USB debugging authorizations", toggle USB debugging off and on, then adb kill-server && adb start-server and replug.

The agent-specific version of this one: adb keeps its key in ~/.android/adbkey. If your agent or MCP client runs adb under a different user or a different HOME (a service, a sandbox, a container), it has a different key, and the phone sees a brand-new computer. It works in your terminal and says unauthorized from the agent. Approve the prompt once more from that context, or point both at the same key.

2. Nothing listed: the cable or the driver

An empty list means USB itself is not carrying data to adb.

Charge-only cables are common, especially the short ones that came with a power bank. Try a cable you have used for file transfer.
Windows needs a USB driver for many phones (Google USB Driver for Pixel, the vendor's driver for Samsung and others). Device Manager shows the phone with a warning icon when it is missing.
Use a port on the computer, not a hub or a monitor's USB port, while you debug.

3. Linux: `no permissions (... are your udev rules wrong?)`

Your user may not open the USB device. Install the community udev rules (android-sdk-platform-tools-common or android-udev-rules, depending on the distro), make sure your user is in the plugdev group, log out and back in, replug.

4. Two adb versions fighting each other

You see adb server version (41) doesn't match this client (39); killing... and the device flickers between online and gone.

Android Studio, Homebrew, scrcpy builds and some agent tools each ship their own adb. Whichever starts the server first wins, the next one kills it. An agent started from an app often has a different PATH than your shell, so it picks a different adb than the one you tested with.

Fix: keep one platform-tools install, put it first on PATH, and give tools the absolute path where they let you.

5. `offline`

The device is connected but adb cannot complete the handshake. Usually an old adb against a newer Android, or a server stuck from an earlier session.

Fix: update platform-tools, adb kill-server, replug, unlock the phone.

6. `more than one device/emulator`

A running emulator counts as a device, and so does a second phone on the same machine. adb refuses to guess.

Fix: pick one with adb -s <serial> ... or set ANDROID_SERIAL=<serial> in the environment the agent runs in.

7. It connects, but taps and screenshots fail

adb itself works, the phone blocks what the agent wants to do with it.

Xiaomi, Redmi, POCO (MIUI / HyperOS): input from adb needs an extra toggle, "USB debugging (Security settings)", below the normal one. Without it taps fail with an INJECT_EVENTS permission error.
Samsung (One UI 6 and later): Auto Blocker blocks commands over the USB cable. Turn it off while you use the phone with an agent.
Banking and some streaming apps mark their windows as secure. Screenshots of those come back black. That is the app protecting itself, not a bug you can fix.
A locked or sleeping screen stops everything. "Stay awake" in Developer options keeps it on while charging.

One more that bites a week later

On Android 11 and later, the phone drops a computer's authorization if it has not connected for about seven days. Everything worked last week, today it is unauthorized again. Developer options has "Disable adb authorization timeout" if that keeps happening.

A 30-second checklist

adb devices -l shows device, not unauthorized or offline?
Data cable, direct port, driver on Windows, udev rules on Linux?
One adb on the PATH the agent actually uses?
One device, or a serial set?
Xiaomi security toggle on, Samsung Auto Blocker off?
Screen unlocked and awake?

Why we wrote this

We build Auten, an MCP server that gives Claude Code, Codex, Cursor or any MCP client hands on a real screen: your computer, and your Android phone over USB (beta). The phone side goes through the same adb authorization as every other tool, so these are the failures we see first. They apply to any adb-based setup, not just ours. Setup notes: https://auten.ai/mcp?utm_source=devto&utm_medium=social

Hit a cause that is not on the list? Put it in the comments with the phone model and we will add it.

Claude Code's computer-use server is missing from /mcp: options on Linux, Windows and Team plans

Auten — Tue, 20 Oct 2026 06:15:09 +0000

Claude Code can now drive a GUI: open an app, click through it, screenshot the result. A lot of people try to turn it on and find the computer-use server simply is not in /mcp.

That is usually not a bug. The built-in feature has a narrow eligibility list. Here is what it is, and what you can do when you are outside it.

Who gets built-in computer use in the CLI

From Anthropic's own docs page (code.claude.com/docs/en/computer-use), as of October 2026, the CLI version needs all of these:

macOS. The CLI version is not available on Linux or Windows. On Windows there is computer use in the Desktop app instead.
A Pro or Max plan. Not Team or Enterprise.
A claude.ai login. Not via Amazon Bedrock, Google Cloud or Microsoft Foundry.
An interactive session. Not in non-interactive mode with -p.

If one of those is false, the server does not show up. Run /status to check your plan and login.

If you are outside that list

On Windows: try computer use in the Claude Desktop app. The docs say it shares the CLI's engine and is switched on in Settings; check its own requirements page for your plan.

On Linux, on a Team or Enterprise seat, via a cloud provider, or in another client (Codex CLI, Cursor's in-editor Agent, Gemini CLI): Claude Code's built-in option is not there. What does work is a computer-use MCP server. MCP is client-side, so it does not care about your plan or which provider serves the model. Claude Code just sees more tools.

There are several open-source ones: per-platform Linux tools (X11, and Wayland-first ones built on AT-SPI), Windows UI Automation tools and ADB tools for Android, plus cross-platform computer-use MCP servers that cover macOS, Linux and Windows in one install. There are also open-source wrappers that let a CLI agent borrow another vendor's desktop computer-use runtime on macOS and Linux X11. Pick by what you need to drive.

The one we build

Disclosure: we make Auten, so weigh this accordingly.

Auten is an MCP server that gives your agent hands on a real screen: macOS, Windows 10/11 and Linux (X11), plus an Android phone over USB (beta). It reads the accessibility tree, clicks, types and reads text, so it works in apps that have no API.

Setup on Linux or macOS:

curl -fsSL https://auten.ai/install | bash
claude mcp add -s user auten -- auten mcp-bridge

On Linux the installer asks for sudo once to apt-install the accessibility and input tools; on macOS it needs no admin rights.

On Windows (PowerShell, no admin rights):

irm https://auten.ai/install.ps1 | iex
claude mcp add -s user auten -- cmd /c npx -y @autenai/mcp

Then check with /mcp and ask in plain words: "Open the settings app and turn on dark mode."

Two things that differ from the built-in tool:

It learns. Once a task works, you save it as a skill with parameters. Next time it replays without an AI call, so repeat runs are faster and cost no tokens.
Passwords stay local. Saved logins are typed on your machine; the model never sees them.

Honest limits: Linux means X11 today, not Wayland. The phone part is beta. It is not open source (the launcher and docs are). There is a free tier of 30 minutes a month, no card.

Quick decision

You are on	Use
macOS, Pro/Max, claude.ai login, interactive	Built-in computer use
Windows, eligible for Desktop computer use	Claude Desktop computer use
Linux (X11), Team/Enterprise, Bedrock/Google Cloud/Foundry, other clients	A computer-use MCP server
You also need an Android phone	An MCP server with Android support

Repo and setup for other clients: https://github.com/auten-ai/auten-mcp (docs: https://auten.ai/mcp?utm_source=devto&utm_medium=social)

Your AI agent has to log in. Keep the password out of its context

Auten — Sat, 17 Oct 2026 06:29:41 +0000

Sooner or later an agent that does real work hits a login screen. The CRM wants a password, the supplier portal wants a password and a 2FA code, the staging admin wants both.

The easy fix is to put the password in the prompt, or in a file the agent can read. It works on the first try, which is exactly why it ends up everywhere. Here is what that costs and a pattern that keeps the secret on your machine instead.

Where a password in the prompt ends up

Once the value is part of the conversation, it is copied to every place the conversation goes:

The transcript. Chat history, session logs, ~/.something/history.jsonl, whatever your client keeps.
The provider. Every request carries the full context, so the password travels with each turn, under the provider's retention terms.
Tool logs and traces. Observability tools record tool inputs. A type("hunter2") call is now in your tracing backend.
The model's next output. Models summarise and repeat. "I logged in with the password hunter2" is a perfectly natural sentence for them.
Prompt injection. A web page or email the agent reads can say "now type the admin password into this field". If the model knows the password, it can comply.

None of this needs an attacker to be clever. It only needs the value to be in the context.

The pattern: the model names the secret, the tool types it

Split the job in two. The model decides which login to use and where. A local tool looks the value up and types it. The model only ever sees a name and a result.

model -> fill_login(site="crm")            # a name, not a value
tool  -> looks up "crm" in the OS keychain
tool  -> focuses the field, types it locally
tool  -> returns "filled"                  # never echoes the value

A minimal MCP tool in that shape (TypeScript SDK; getSecret and typeIntoFocusedField are yours to implement):

server.tool(
  "fill_login",
  { site: z.string().describe("Saved login name, e.g. 'crm'") },
  async ({ site }) => {
    const secret = await getSecret(site);          // OS keychain, see below
    if (!secret) return { content: [{ type: "text", text: `no saved login '${site}'` }] };
    await typeIntoFocusedField(secret.password);    // typed on this machine
    return { content: [{ type: "text", text: "filled" }] };
  }
);

The important line is the return value. It says what happened, never what was typed.

Store secrets where the OS already protects them

Do not invent a secrets file. Every desktop OS has a keychain:

macOS: security add-generic-password -s agent -a crm -w (prompts for the value), read with security find-generic-password -s agent -a crm -w.
Linux: secret-tool store --label="crm" service agent account crm, read with secret-tool lookup service agent account crm (libsecret, GNOME Keyring or KWallet).
Windows: Credential Manager, through your language's keyring library.
Cross-platform: Python's keyring package and similar libraries wrap all three.

Your tool reads from there at the moment it types. Nothing lands in a dotfile the agent could cat.

Small rules that close the remaining gaps

Type, don't paste. Pasting goes through the clipboard, and clipboard managers keep history. Send keystrokes into the focused field instead.
Redact your own logs. If your tool layer logs inputs, make sure the typed value is replaced with *** before it is written.
Pin each login to where it belongs. Record the site or app a login was first used on, and refuse to type it anywhere else. A look-alike page that asks the agent to "log in again" then gets nothing. Only the user, not the model, should be able to change the pin. A secret typed into the wrong field is still leaked.
Treat 2FA codes the same way. Generate or read the code in the tool, type it, return "filled". The model does not need to see it either.
Keep reading tools blind to fields. If the agent can screenshot or read the screen, password fields should come back masked, which most toolkits already do. Do not add a "read value" tool that undoes it.

Why we care

We build Auten, an MCP server that gives Claude Code, Codex, Cursor or any MCP client hands on a real screen: your computer (Mac, Windows, Linux) and your Android phone over USB (beta). Logins work this way: passwords stay on your computer and are typed locally, so the model never sees them. Each saved login is pinned to the site or app it was first used on; on a different origin Auten refuses and types nothing. A reader asked us about exactly that gap on dev.to, and we shipped it the same evening. If you want to try it: auten.ai.

How do you handle credentials in your agent setups today? Env vars, a vault, or "it's in the prompt for now"? Tell us in the comments.

Your computer-use agent clicks 20 pixels off: screenshots vs the accessibility tree

Auten — Wed, 14 Oct 2026 06:04:35 +0000

Every computer-use agent has to answer one question before it can click anything: what is on the screen right now?

There are two ways to answer it. Send the model a screenshot and let it find the button in the pixels. Or ask the operating system, which already knows: every serious UI toolkit publishes an accessibility tree for screen readers, with the role, name, state and position of each control.

Most demos use screenshots because they work everywhere. In practice you want both, in a specific order. Here is how each one behaves, how to look at the tree yourself, and where each breaks.

What the accessibility tree gives you

A screenshot is a grid of pixels. The tree is a list of facts:

button  "Export"        enabled   @ (812, 64)
textbox "File name"     focused   value "report-q3"
menuitem "CSV"          @ (830, 140)

That changes three things for an agent:

It clicks the element, not a guessed coordinate. The agent says "press the Export button" and the OS hands back exactly where it is. No off-by-20-pixels misses on a crowded toolbar.
It knows state. Disabled, checked, focused, expanded, the current value of a field. From a screenshot the model has to infer a greyed-out button from a slightly lighter shade.
It is cheap to send. A screen with 40 controls is a few dozen short lines of text. A screenshot costs roughly width x height / 750 tokens on Claude (per Anthropic's vision docs), so about 1,600 tokens for a 1092x1092 image, every single step. Text is also something the model can search and quote precisely.

Where the tree is empty or lies

The tree is only as good as the app's accessibility work. The usual gaps:

Canvas apps. Design tools' canvases, games, maps, charting widgets. The window is one big element with nothing inside.
Remote screens. A VNC, RDP or Citrix window is just a video. The tree stops at the window frame.
Electron and Chromium, until asked. Chromium builds its full web accessibility tree only when it detects an assistive technology. On macOS, Electron apps expose it once a client sets AXManualAccessibility; Chrome itself has --force-renderer-accessibility. Before that, you see a shell with almost no children.
Custom-drawn controls with no names. You get button "" twelve times in a row.
Stale positions during animations and scrolling. Read the tree, then act fast, or read it again.

That is why screenshots stay in the toolbox: they work on anything that draws pixels.

The screenshot trap: coordinates and scaling

If you do click from screenshots, the most common silent failure is scaling, not the model's eyesight.

On a Retina Mac the screenshot is in physical pixels and clicks are in logical points (half). On Windows, display scaling of 125% or 150% does the same thing. And many agents downscale the screenshot before sending it to the model, so the model's coordinates are in a third coordinate space.

Symptoms: clicks land up-left or down-right of the target, consistently, by a fixed ratio. Fix: keep one conversion function from "image the model saw" to "screen points" and run every click through it. Test it by clicking the four corners of a known window.

Look at the tree yourself

Before you decide which approach your agent needs for an app, spend two minutes with the platform inspector:

macOS: Accessibility Inspector (Xcode, Open Developer Tool). Hover anything to see role, title and frame.
Windows: Accessibility Insights for Windows, or Inspect.exe from the Windows SDK. Both read UI Automation.
Linux: Accerciser, which reads AT-SPI. Most of this assumes X11; Wayland deliberately limits what other programs can see and inject.
Android: adb shell uiautomator dump /sdcard/view.xml && adb pull /sdcard/view.xml. You get the view hierarchy with text, resource ids and bounds.

If the inspector shows named buttons and fields, a tree-first agent will be fast and accurate there. If it shows one big pane, plan for screenshots and OCR.

The order that works

Tree first. List the interactive elements with names, roles and positions. Let the model pick one by id.
Text next. When the tree has no labels, OCR the window and match on visible text.
Screenshot last. For canvases, icons without names, or "is this the right page?" checks, send the image.
Verify after acting. Re-read the tree or the text after each important step. Do not assume the click worked.

Keeping the screenshot as the fallback instead of the default makes most steps cheaper and more precise, and you still cover the apps that draw everything themselves.

Why we care

We build Auten, an MCP server that gives Claude Code, Codex, Cursor or any MCP client hands on a real screen: your computer (Mac, Windows, Linux) and your Android phone over USB (beta). It works in exactly this order: the agent gets a numbered list of real buttons and fields from the accessibility tree, and OCR and screenshots are there when an app has no accessibility info. If you want to try it: auten.ai.

Which apps have the worst accessibility trees you have had to automate? Tell us in the comments.

Your MCP server works in the terminal but not in Claude Desktop or Cursor: 8 causes

Auten — Sun, 11 Oct 2026 06:23:24 +0000

You run your MCP server by hand, it starts, nothing crashes. You add it to Claude Desktop, Cursor or another client and it shows up red, "failed", or connects and then no tool works.

Almost always the server is fine. The difference is the environment the client launches it in. These are the causes we keep hitting, roughly in order of how often.

1. Something writes to stdout

With the stdio transport, stdout IS the protocol. Every byte on it must be a JSON-RPC message. One console.log("server started"), a banner from a library, or a deprecation warning printed to stdout, and the client fails to parse the stream.

Fix: send all logs to stderr (console.error in Node, print(..., file=sys.stderr) in Python, the logging module defaults to stderr). Clients usually capture stderr into their log file, so you lose nothing.

2. The client does not have your shell's PATH

On macOS, an app started from the Dock or Finder does not read .zshrc or .bash_profile. It gets the minimal launchd PATH, /usr/bin:/bin:/usr/sbin:/sbin. If node came from Homebrew (/opt/homebrew/bin) or nvm (~/.nvm/versions/...), the client cannot find npx or node, and you get spawn npx ENOENT.

Fix, pick one:

Use the absolute path as the command: run which npx in your terminal and paste the result.
Set PATH explicitly in the server's env block in the client config.

With nvm, the absolute path also pins the Node version, which avoids cause 6.

3. Your environment variables are not there either

The same applies to API keys and settings you exported in your shell. The server process only gets what the client passes it.

Fix: put them in the env block of that server's config entry, not in your shell profile.

4. npx is waiting or still downloading

npx some-package on a machine that does not have it cached first downloads it. Without -y it can stop to ask "Ok to proceed?", and nobody is there to answer. Even with -y, a slow first download can outlast the client's startup timeout, so the first launch fails and the second one works.

Fix: always npx -y, and run the exact command once in a terminal so the package is cached before the client starts it.

5. Relative paths and the working directory

Clients do not promise a working directory. On macOS it is often /. A server that opens ./config.json or writes ./data.db works from your project folder and fails everywhere else.

Fix: absolute paths in args, or resolve paths relative to the script file, not the current directory.

6. A different Node or Python than you think

Your terminal uses the version from nvm, pyenv or a virtualenv. The client may hit the system one, or an old Homebrew one. Syntax errors at import time or "unsupported engine" warnings in the log are the sign.

Fix: point the command at the exact interpreter (/path/to/venv/bin/python, the nvm node), not a bare python or node.

7. Windows: npx is not an executable

On Windows npx is npx.cmd, a batch file, and some clients spawn the command without a shell, so "command": "npx" fails.

Fix: launch it through cmd:

{
  "command": "cmd",
  "args": ["/c", "npx", "-y", "your-mcp-package"]
}

8. It is configured for a different project (Claude Code)

Added from the comments, thanks to @heyitsjakub. claude mcp add uses the local scope by default: the server is registered for the project you ran it in, and nowhere else. Open another project and it looks like the server vanished, while the config is fine.

Fix: run claude mcp list inside the project where it is missing. For every project, add it with --scope user. To share it with your team, use --scope project, which writes a .mcp.json at the repo root (Claude Code asks each person to approve it once). Cursor has the same split: ~/.cursor/mcp.json for all projects, .cursor/mcp.json for one.

Where to look first

Claude Desktop logs: ~/Library/Logs/Claude/ on macOS (mcp.log plus one mcp-server-<name>.log per server), %APPDATA%\Claude\logs on Windows. Your stderr ends up there.
Claude Code: claude mcp list shows which servers connect, and /mcp inside a session shows their status.
MCP Inspector: npx @modelcontextprotocol/inspector <your command> <args> starts the server the way a client would and lets you call each tool by hand. If it works there and not in the client, the problem is the client's environment (causes 2 to 6).
Restart for real. Most clients read the config only at startup. On macOS that means Cmd+Q, not closing the window.

A 30-second checklist

Nothing but JSON-RPC on stdout?
Command is an absolute path, or PATH is set in env?
API keys in the config's env, not only in your shell?
npx -y, and the package already cached?
No relative paths?
The interpreter the client runs is the one you tested with?
On Windows, cmd /c npx?
In Claude Code, added in the right scope?

Why we wrote this

We build Auten, an MCP server that gives Claude Code, Codex, Cursor or any MCP client hands on a real screen: your computer and your Android phone (beta). It is launched with npx -y @autenai/mcp, so every item on this list is a support question we have either hit ourselves or expect to.

Hit another cause? Put it in the comments and we will add it.

Why your computer-use agent silently does nothing on macOS

Auten — Fri, 09 Oct 2026 09:29:11 +0000

You wire a computer-use MCP server into Claude Code, Cursor or Codex, ask it to click a button, and the tool call comes back "ok". Nothing on screen moves. Or the screenshot it reasons over is just your wallpaper.

Nine times out of ten this is not the model and not the MCP server. It is macOS privacy permissions (TCC), and the frustrating part is that most of the failures are silent. This is the checklist we wish we had on day one.

Two permissions, two different failures

A screen-driving agent needs two separate grants in System Settings > Privacy & Security:

Accessibility lets a process read other apps' UI trees (buttons, fields, labels) and post synthetic mouse and keyboard events.

Without it, Accessibility API calls fail with kAXErrorAPIDisabled (-25211). Many tools swallow that and return an empty element list.
Synthetic events posted with CGEventPost are dropped without any error. The click "succeeds" and nothing happens.

Screen Recording lets a process capture other apps' pixels.

Without it, a capture typically shows the desktop and menu bar, but not the contents of other apps' windows. A vision model then confidently describes an empty desktop.
Less obvious: window titles of other apps (kCGWindowName from CGWindowListCopyWindowInfo) are withheld too, so "find the window called Invoice" fails even if you never take a screenshot.

If your agent can list elements but its screenshots look empty, you are missing Screen Recording. If it can see everything but clicks do nothing, you are missing Accessibility.

The grant usually belongs to the app hosting your agent

This is the part that costs people an afternoon. macOS attributes a permission request to the "responsible" app, which for a command-line tool is usually the GUI app that launched it, not the binary itself.

MCP server started by Claude Code in Terminal or iTerm: the grant Terminal (or iTerm) has is what counts.
Started by Cursor, VS Code or a desktop chat client: that app's grant counts.
Started by launchd (a LaunchAgent): the process itself is responsible, so the grant has to be on the exact binary in ProgramArguments.

So "I gave node Accessibility and it still fails" is normal: node was never the responsible process. Grant the host app, restart it fully (quit, not just close the window), and try again. Permission changes are not picked up by already running processes.

The flip side is worth saying plainly: granting Accessibility to Terminal means everything you run from Terminal can drive your Mac. If that bothers you, run the agent from a dedicated terminal app you use only for it.

Check what your agent actually has

Run this from the same app that launches your agent, so it inherits the same responsible process:

cat > /tmp/tcc-check.swift <<'EOF'
import ApplicationServices
import CoreGraphics
print("Accessibility:   ", AXIsProcessTrusted())
print("Screen Recording:", CGPreflightScreenCaptureAccess())
EOF
swift /tmp/tcc-check.swift

Both functions only check, they never show a prompt. false on either line explains most "it does nothing" reports. (Needs the Xcode command line tools for swift.)

To watch macOS decide in real time while your agent tries to act:

log stream --debug --predicate 'subsystem == "com.apple.TCC"'

The log shows which process TCC evaluated and whether it was allowed, which settles the "who is responsible" question without guessing.

The toggle is on, and it still fails

Three causes we keep running into:

The binary changed. A grant is tied to the code signature. For an ad-hoc signed binary that means its exact hash, so every rebuild, or a package-manager upgrade that replaces the binary, silently invalidates the grant while the switch in Settings still shows "on". Fix: remove the entry with the minus button and add it again, or sign your own tools with a stable identity (a free Apple Development certificate is enough).
Stale entries. Reset one service for one app and let it ask again:

   tccutil reset Accessibility com.apple.Terminal
   tccutil reset ScreenCapture com.apple.Terminal

Use the bundle id of whichever app hosts your agent.

A pending system prompt. Recent macOS versions periodically ask you to reconfirm screen access for some apps. An unattended agent cannot answer that dialog, so if captures suddenly go blank after weeks of working, look at the screen for a waiting prompt first.

A short pre-flight before you blame the model

Which app launches the agent? That app needs both grants.
Fully quit and reopen it after granting.
Run the Swift check from that app: both true?
Screenshots empty -> Screen Recording. Clicks ignored -> Accessibility.
Toggle on but failing after an update -> remove and re-add the entry.

Why we care

We build Auten, an MCP server that gives Claude Code, Codex, Cursor or any MCP client hands on a real screen: your computer and your Android phone (beta). On macOS, its installer runs a permissions setup step and auten status shows what is connected and what is missing, because silent permission failures were the first thing that broke for us too.

If you are hitting a TCC case not covered here, describe it in the comments. We collect these.

I gave Claude Code hands: it drives my real Mac and Android phone

Auten — Wed, 07 Oct 2026 21:07:32 +0000

Most "AI agents" stop at text. They plan, they explain, they hand you a snippet to run yourself.
Auten is an MCP server that closes that last gap: it gives your agent a real screen to work on —
your computer (Mac, Windows, Linux) and your Android phone — so it clicks, types, and reads the
screen like a person sitting at the machine. Even in apps with no API.

I wired it into Claude Code. Here is what that actually looks like.

One line to install

Auten ships as an MCP server on npm, so any MCP client can use it:

claude mcp add auten -- npx -y @autenai/mcp

That is it for Claude Code. Cursor, Codex, and other MCP clients use the same package with their
own config. Nothing else to run on the machine — the piece on the device is thin (hands and eyes),
the brain is your agent.

Giving it a goal, not a script

The thing that surprised me: you do not script coordinates or write selectors. You give the agent a
goal, and it reads the accessibility tree to find what it needs.

A real task I ran: "open System Settings and turn on Night Shift from sunset to sunrise." The agent
listed the on-screen elements, clicked into Displays, found the Night Shift button by its label,
opened the schedule dropdown, and picked the option. When I asked it to do the same on my phone —
"turn on battery saver" — it drove the Android Settings app the same way.

No API exists for either of those. It worked because Auten operates the real UI, not an integration.

The parts that make it usable, not just a demo

A computer-use agent is only useful if it is repeatable, cheap, and safe. Three things do that:

Learns a task once, replays with no AI call. Record a task once and Auten saves it as a skill with parameters. Next time Auten replays it deterministically — seconds, no model tokens.
Self-heals when the UI shifts. When a button moves or a layout changes and a saved skill breaks, it repairs the step from where it failed instead of dying.
Secrets stay local. Passwords and keys are typed on your machine through a local login path; the agent never sees the value.

Where it is honest about limits

This is early. It is genuinely good at UI navigation, form filling, and multi-step tasks across apps,
and it is best when you let it confirm the result after each important step rather than firing blind.
It is not magic — give it a clear goal, check the outcome, and it compounds: the second run of any
task you teach it is deterministic.

If you are building agents that should do real work instead of just chatting, this is the missing
hand. Try it: auten.ai/mcp

DEV Community: Auten

Your computer-use agent's clicks do nothing in admin windows on Windows

What UIPI blocks

Check it in thirty seconds

Fixes, in the order we would try them

A short pre-flight before you blame the model

Why we care

Your AI agent can't see your Android phone: adb 'unauthorized', 'offline' and 5 other causes

1. unauthorized: the phone never approved this computer

2. Nothing listed: the cable or the driver

3. Linux: no permissions (... are your udev rules wrong?)

4. Two adb versions fighting each other

5. offline

6. more than one device/emulator

7. It connects, but taps and screenshots fail

One more that bites a week later

A 30-second checklist

Why we wrote this

Claude Code's computer-use server is missing from /mcp: options on Linux, Windows and Team plans

Who gets built-in computer use in the CLI

If you are outside that list

The one we build

Quick decision

Your AI agent has to log in. Keep the password out of its context

Where a password in the prompt ends up

The pattern: the model names the secret, the tool types it

Store secrets where the OS already protects them

Small rules that close the remaining gaps

Why we care

Your computer-use agent clicks 20 pixels off: screenshots vs the accessibility tree

What the accessibility tree gives you

Where the tree is empty or lies

The screenshot trap: coordinates and scaling

Look at the tree yourself

The order that works

Why we care

Your MCP server works in the terminal but not in Claude Desktop or Cursor: 8 causes

1. Something writes to stdout

2. The client does not have your shell's PATH

3. Your environment variables are not there either

4. npx is waiting or still downloading

5. Relative paths and the working directory

6. A different Node or Python than you think

7. Windows: npx is not an executable

8. It is configured for a different project (Claude Code)

Where to look first

A 30-second checklist

Why we wrote this

Why your computer-use agent silently does nothing on macOS

Two permissions, two different failures

The grant usually belongs to the app hosting your agent

Check what your agent actually has

The toggle is on, and it still fails

A short pre-flight before you blame the model

Why we care

I gave Claude Code hands: it drives my real Mac and Android phone

One line to install

Giving it a goal, not a script

The parts that make it usable, not just a demo

Where it is honest about limits

1. `unauthorized`: the phone never approved this computer

3. Linux: `no permissions (... are your udev rules wrong?)`

5. `offline`

6. `more than one device/emulator`