Repository navigation
Homebrew-cask adb is not in resolveAndroidBinary's fallbacks, so list-devices silently drops Android without the shell PATH #1457
Description
resolveAndroidBinary (packages/tool-server/src/utils/android-binary.ts) looks for adb on PATH, then under android.sdkRoot / $ANDROID_HOME / $ANDROID_SDK_ROOT, then under defaultAndroidRoots(). None of those cover /opt/homebrew/bin/adb (or /usr/local/bin/adb on Intel), which is where brew install --cask android-platform-tools puts it. That cask is the macOS route the missing-adb hint in check-deps.ts:40 recommends.
So when the tool-server runs without the user's shell PATH, a Homebrew-cask user's adb is not found and list-devices returns no Android devices with no note. Its description says an empty result "usually means ... Android platform-tools ... is not installed", so the agent tells the user to install something they already have. Examples: an editor launched from the Dock, an absolute-path MCP entry (the #1287 workaround, and what #1344 writes), or a session that reuses a tool-server another such client started. Android Studio users are unaffected, because ~/Library/Android/sdk is in the default roots.
Repro
Sandbox HOME without ~/Library/Android/sdk, a stub adb in a scratch dir standing in for /opt/homebrew/bin/adb, reporting one attached phone (R58N12345AB device). Start the tool-server (node packages/tool-server/dist/index.js start, own ARGENT_PORT) and POST /tools/list-devices:
env -i HOME=<sandbox> PATH=/usr/bin:/bin:/usr/sbin:/sbin: no Android entry, and nonotefield.- Same, with the stub's dir prepended to PATH:
{"platform":"android","serial":"R58N12345AB","kind":"device",...}.
The real cask install on macOS: /opt/homebrew/bin/adb -> /opt/homebrew/Caskroom/android-platform-tools/37.0.1/platform-tools/adb.
Activity
adityamukesh commentedon Oct 15, 2026
I'd like to take this on. The proposed scope would be macOS-only fallbacks for
/opt/homebrew/bin/adband/usr/local/bin/adb, after the existing PATH and SDK-root probes, retaining executable checks and the current cache behavior. I'd add focused tests for both Homebrew prefixes, existing resolution precedence, and missing or non-executable candidates, without changing emulator resolution.Would you be happy for me to open a PR with that scope? I plan to use AI assistance and disclose it in the PR; I haven't reproduced or tested the fix yet.