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

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.