adb on Windows: Git Bash rewrites /sdcard paths, the USB debugging prompt needs a live adb server, two devices need -s

Observed October to November 2026 using adb from Google's platform-tools (installed through winget, not on PATH) against Android 13 phones on Windows hosts, from Git Bash and from an SSH session. The adb version was not recorded. Only the device-debugging mechanics are described here.

/sdcard paths are rewritten by Git Bash

Git Bash converts Unix-style arguments for native Windows programs. An Android path given to adb, as in

adb shell uiautomator dump /sdcard/ui.xml

was rewritten before adb saw it. The dump file ended up at a path shaped like /Files/Git/sdcard/ui.xml (a fragment of the Git installation path was prepended), so a later cat /sdcard/ui.xml on the device returned nothing. This looks like a permissions failure and is not one. The command itself reports success.

Two ways around it were recorded:

• Set MSYS_NO_PATHCONV=1 for the session (export MSYS_NO_PATHCONV=1), after which the /sdcard form and adb pull /sdcard/ui.xml . worked.
• Avoid a device path entirely: adb exec-out uiautomator dump /dev/tty writes the XML to stdout, so there is no temporary file and no pull. This was the form that stayed in use.

Reading the screen as text from that dump (filtering text="..." attributes, and bounds="[x1,y1][x2,y2]" for tap targets) was reported as far cheaper than viewing screenshots of a 1080 by 2400 display. Tapping the centre of a node's bounds, adb shell input tap <cx> <cy>, was more reliable than coordinates read off a downscaled screenshot. When a screenshot is viewed at reduced size, coordinates read from it are not device pixels and have to be scaled up by the reduction factor before being passed to input tap. input text could not type into some fields on one Samsung phone.

The USB debugging authorisation prompt and the adb server

On a Windows PC administered over SSH, the phone's "Allow USB debugging" prompt did not appear on first connection. The note's explanation: an adb server started from an SSH session dies when that session ends, so the prompt shows only while some live session holds adb open. Getting the first authorisation required adb kill-server and adb start-server while someone was at the phone to tap Allow. The explanation was inferred from the behaviour; no test of a server started by a long-lived process (for example a scheduled task) was recorded, so it is not known whether that would avoid the problem.

Related, from the earlier setup on another PC: adb devices showing nothing usually meant the cable or the USB debugging toggle rather than adb, since the phone dropped off USB several times.

Two devices attached: "more than one device/emulator"

After a second Android phone was attached to the same PC, bare adb commands failed:

error: more than one device/emulator

Background lookups that used adb produced errors for every item until the commands were pinned. Two forms were used:

adb -s <serial> shell input tap 540 1200
export ANDROID_SERIAL=<serial>

A helper process that used the environment variable (ANDROID_SERIAL) for every call was recorded as working. The notes also recommend stopping any stray worker process before starting a second one, because stale workers kept writing errors while the first problem was being fixed. The serial for a connected device comes from adb devices.