Fixing scrcpy that won't connect or open on macOS

You type scrcpy, and one of three things happens. Nothing at all. A line of red text about not finding a device. Or macOS throws up a dialog saying it can’t verify the app, or quietly kills the process. All three look like “scrcpy is broken on my Mac”, but they are different problems with different fixes, and most of the wasted hours I’ve seen come from treating them as one.

This is for anyone running scrcpy on a Mac, Intel or Apple Silicon, who has a phone they own or are authorised to test and can’t get a mirror window. If you came here from scrcpy issue #3505, the order below is the one I’d work through for that kind of report. I haven’t reproduced that reporter’s exact setup, so compare your own error text with theirs as you go.

The core idea is to test in layers. First, does the Mac see the phone through adb. Second, does the scrcpy binary run at all. Third, only then, do scrcpy flags and video settings matter. Skip straight to layer three and you’ll chase ghosts.

What you need

• a Mac running a current macOS release, with Terminal access
• Homebrew installed (free, from brew.sh)
• scrcpy installed through Homebrew (brew install scrcpy), which is free
• adb from Google’s platform-tools. Homebrew’s scrcpy formula pulls in adb as a dependency, or you can use brew install --cask android-platform-tools
• an Android phone you own or are authorised to test, with a data USB cable (not a charge-only cable)
• USB debugging enabled on the phone. If the toggle is greyed out, see fixing a greyed-out USB debugging toggle on Android
• about 20 minutes. no paid accounts or tools needed

Step by step

1. Confirm adb sees the phone before touching scrcpy

scrcpy talks to the phone through adb. If adb can’t see the device, scrcpy can’t either, and no amount of reinstalling scrcpy will help. Plug the phone in, unlock it, and run:

adb devices

Expected output:

List of devices attached
R58M12ABCDE device

The word at the end matters. device means good. unauthorized means the phone is waiting for you to tap “Allow USB debugging” on its screen. offline means a stale connection. An empty list means the Mac doesn’t see the phone over USB at all.

If it breaks: for unauthorized, unlock the phone and look for the RSA key prompt, tick “always allow”, tap allow. For an empty list, swap the cable first (charge-only cables are the most common cause), then try a different port, and set the phone’s USB mode to “File transfer” in the notification shade. For offline, run adb kill-server then adb devices again. Google’s adb documentation covers the server and device states in detail.

2. Make sure there is only one adb on the Mac

This one bites people who installed Android Studio, platform-tools and Homebrew at different times. Each ships its own adb, and when two different versions fight over port 5037 you get errors like “adb server version doesn’t match this client; killing…”. Check which adb your shell uses:

which -a adb
adb --version

On Apple Silicon, Homebrew lives in /opt/homebrew/bin. On Intel it is /usr/local/bin. If you see two or three paths, pick one. You can also tell scrcpy exactly which adb to use:

ADB=/opt/homebrew/bin/adb scrcpy

scrcpy reads the ADB environment variable for this, and it is documented in the scrcpy README.

If it breaks: run adb kill-server, close Android Studio (it likes to restart its own adb), then run adb devices again so a single server starts.

3. Run scrcpy from Terminal and read the actual error

Don’t launch from Spotlight or a double-click. Run it in Terminal so you see everything it prints:

scrcpy --version
scrcpy

A healthy start prints the scrcpy version, the device name, and then opens a window. The failure messages that matter:

• ERROR: Could not find any ADB device: layer one is still broken, go back to step 1
• command not found: scrcpy: Homebrew’s bin directory isn’t on your PATH, or scrcpy isn’t installed
• zsh: killed or Killed: 9: macOS terminated the binary, which points at quarantine or signing (steps 4 and 5)
• Server connection failed or a server push error: adb works but the on-device server didn’t start, usually a version mismatch (step 6)

If it breaks: copy the first error line exactly. the first line is the useful one, later lines are usually fallout.

4. Check for the Gatekeeper quarantine flag

When you download a binary outside the App Store, macOS tags it with a com.apple.quarantine extended attribute. Gatekeeper then blocks it or shows the “cannot be opened because the developer cannot be verified” dialog. Homebrew-installed scrcpy usually doesn’t have this flag, but a scrcpy folder downloaded from a GitHub release zip, or copied from another machine, often does. Look:

xattr -l "$(which scrcpy)"

If the output includes com.apple.quarantine, that’s your culprit. For a downloaded folder, clear it recursively:

xattr -dr com.apple.quarantine ~/Downloads/scrcpy-macos-aarch64-v3.0

Then run ./scrcpy from inside it again. Apple’s own explanation of what Gatekeeper is doing, and the per-app override in System Settings, is on Apple Support. Only strip quarantine from files you trust, meaning the official scrcpy release page and nothing you picked up from a random mirror.

If it breaks: if the dialog still appears, open System Settings, Privacy & Security, scroll to the blocked item and choose “Open Anyway”. Then re-run in Terminal.

5. Inspect and repair the code signature

If the process dies with Killed: 9 and quarantine is clean, the binary’s code signature may be invalid. This happens after copying binaries between architectures, after a partial download, or after something modified the file. Check it:

codesign -dv --verbose=2 "$(which scrcpy)"
codesign --verify --verbose "$(which scrcpy)"

A valid binary prints signature details. A damaged one prints something like “invalid signature” or “code object is not signed at all”. Apple Silicon is strict here: unsigned arm64 binaries won’t run. The quick local fix is an ad-hoc signature:

codesign --force --sign - "$(which scrcpy)"

Do the same for the scrcpy-server file only if you hit an explicit error about it. An ad-hoc signature satisfies the local kernel check on your own machine. It doesn’t make the binary trustworthy, so if you don’t know where the file came from, reinstall (step 6) rather than sign it.

If it breaks: a Homebrew-managed binary that needs re-signing is a sign the install is damaged. Skip the patch and do the clean reinstall next.

6. Reinstall cleanly with Homebrew

When steps 4 and 5 turn up anything odd, or when scrcpy and its server file disagree on version, the fastest fix is a clean reinstall. Homebrew tracks the right architecture and dependencies for you:

brew update
brew uninstall scrcpy
brew cleanup
brew install scrcpy
brew doctor

brew doctor is worth reading. It flags a wrong PATH order, a stray /usr/local install on an Apple Silicon Mac, and permission problems. If you previously unzipped a manual scrcpy download, delete it, so you aren’t running an old binary by accident:

which -a scrcpy

You want exactly one path, under Homebrew’s prefix. After that, scrcpy --version should print a clean version line.

If it breaks: if brew install fails midway, run brew update-reset, then try once more. If the failure is a download error, it’s usually network or a VPN, so turn the VPN off for the install.

7. Reset the adb server and retry

With a clean binary and a single adb, restart the whole chain in order:

adb kill-server
adb start-server
adb devices
scrcpy

Expected: adb devices shows device, then the scrcpy window opens within a couple of seconds. If the window opens but is black, that’s a video encoder issue rather than a connection one. Try scrcpy --video-codec=h264 or lower the resolution with -m1024, and check the scrcpy README for current flag names, since options get renamed between major versions.

If it breaks: reboot the phone, then the Mac. A hung USB stack on either side is common enough that I do this before any deeper debugging.

8. Try wireless only after USB works

Wireless adb adds a second set of failure modes (Wi-Fi isolation, different subnets, expired pairing), so get USB working first. Once it does, from the same Mac:

adb tcpip 5555
adb connect 192.168.1.50:5555
scrcpy

Use your phone’s real IP from Settings, Wi-Fi. On Android 11 and later you can pair without a cable using adb pair <ip>:<port> and the code shown in Developer options. If scrcpy then complains about multiple devices, name the target with scrcpy -s 192.168.1.50:5555.

If it breaks: guest Wi-Fi and office networks often block device-to-device traffic. Test on a home or hotspot network before blaming the Mac.

Common pitfalls

• charge-only USB cables. the phone charges, the Mac sees nothing. Keep one known-good data cable and label it.
• fixing scrcpy when adb is the problem. If adb devices doesn’t say device, nothing in steps 4 to 7 can help.
• running sudo on scrcpy or adb. it creates a root-owned adb server that your normal user then can’t talk to. If you did this, run sudo adb kill-server once and go back to plain commands.
• mixing install sources. Android Studio’s adb, a manual platform-tools unzip and Homebrew’s adb will each start their own server. One source, one path.
• stripping quarantine from files you don’t recognise. xattr -dr is a legitimate fix for a trusted release download, but it also turns off a safety check, so use it on the official files only.

Scaling this

At 10 phones on one Mac, the failures are mostly physical. A cheap unpowered USB hub drops devices, so use a powered hub, label each phone’s serial, and always pass -s <serial> to scrcpy so you never mirror the wrong handset. Mirroring many screens at once costs CPU, and I’d check whether you need a dedicated GPU for scrcpy before buying hardware.

At 100 phones, one Mac stops being the right shape. You want a rack, stable power, a script that records serial to slot, and a way to see which devices went offline. Plain scripts around adb devices get you surprisingly far. Beyond that, look at the tools in best open source Android device farm tools.

At 1000, it’s a device farm problem: inventory, health checks, remote access, and routine hardware replacement.

One case where a local Mac and a cable is the wrong answer is when the thing you need to test is a real Android phone in Singapore and you’re not in Singapore. cloudf.one rents real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, controlled from the browser. It is Singapore-only. One caveat I want to be exact about: cloudf.one has no self-service adb. adb and Appium reach a rented phone only through a WireGuard tunnel that we set up on request, by emailing [email protected]. For quick manual checking, the browser control is the intended route. If your own phone is on your desk, ignore this and keep fixing the Mac.

Where to go next

• fixing scrcpy keyboard and mouse input that doesn’t work on Oppo phones, for when the window opens but input is dead
• best scrcpy configuration for low latency mobile gaming, once the connection is stable and you want it to feel responsive
• best adb GUI tools, if you’d rather click than type commands
• the full index at /blog/ for more adb and scrcpy tutorials

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-03.