LocalSend gets stuck on ‘Waiting for response’ when I try to send files between devices on the same network. I already checked that both devices are connected and visible, but the transfer never starts. I need help figuring out what could be blocking the connection and how to get LocalSend working again.
LocalSend hangs on 'Waiting for Response'
I ran into this a few times. Usually it means both devices show up, so they are on speaking terms, but the receiving side never properly accepts the transfer.
The first thing I check is whether LocalSend is still open in the foreground on the device getting the file. If I had switched away from it, the transfer often sat there forever. A lot of Android phones are agressive with battery saving, and they kill or freeze apps fast when you leave the screen.
Check your network first
Both devices need to be on the same local network, not something close enough. I had one device on guest Wi-Fi once, and LocalSend still showed the other device, but the file would not go through. Same kind of mess happens with VPNs, mobile data, or a hotspot.
What helped me was simple stuff. Reconnect both devices to the same Wi-Fi. Close LocalSend fully on both ends. Open it again and retry. Sounds dumb, fixed it more than once.
Firewall and permissions trip people up
On Windows, firewall rules are a common blocker. Windows Defender has been the culprit for me before, and there was no clear pop-up saying it blocked anything. If you want a fast test, temporarily check whether the firewall is stopping the app, then retry the transfer.
On macOS, look at Local Network access in system settings. If that permission is off, LocalSend tends to fail in ways that are not obvious. On Android, check file and storage access too, or the app might see the sender but fail when it tries to receive the file.
If it keeps happening
I would restart LocalSend on both devices before doing anything fancy. After that, send a tiny file first. A small photo or text file is enough. If small transfers work and big ones fail, the issue feels more like connection stability than device discovery.
I have also seen flaky behavior on mesh Wi-Fi setups and routers with client isolation turned on. Devices look visible, but direct transfer traffic gets blocked or dropped.
If large transfers keep failing, mostly on macOS from what I saw, MacDroid or OpenMTP tend to be less annoying as fallback options.
7 Likes
If both devices are visible, discovery works. The hang is often in the handshake step.
A few things I’d try, separate from what @mikeappsreviewer already listed:
-
Check the device name for weird characters.
I’ve seen transfer apps choke on emojis, slashes, and long custom names. Rename both devices to something short, plain, and retry. -
Turn off Private DNS or ad blocking.
On Android, Private DNS, AdGuard, NextDNS, or similar filters sometimes mess with local traffic. Same for desktop apps with network filtering. Disable them for a test. -
Force a different network path.
If your router has both 2.4 GHz and 5 GHz bands under one SSID, split test it. Put both devices on 5 GHz, or both on 2.4 GHz. Mixed band steering causes odd local transfer bugs on some routers. -
Clear LocalSend app data.
Not only restart. Clear cache, and if needed app data on one side. Corrupt saved device info is a thing. You’ll need to re-approve permsissions after. -
Test receive mode in reverse.
Send a tiny file from device B to device A. If one direction fails and the other works, the stuck side is usually the receiver, not the sender. -
Check the system clock.
Sounds dumb, but if one device has the wrong date/time by a lot, some apps fail session setup. Auto time on both.
I slightly disagree with firewall being the first place to look unless one side is Windows. If both are phones or tablets, network filtering, DNS, or app sleep is more common from what I’ve seen.
If your setup is Mac + Android and LocalSend keeps wasting your time, MacDroid is worth a look. It’s more of a direct file transfer tool than a local broadcast app, so fewer moving parts.
My order would be: rename devices, disable DNS/ad blockers, clear app data, reverse the transfer, test on same Wi-Fi band. That usualy finds it fast.
One angle I don’t see mentioned enough by @mikeappsreviewer or @kakeru is the actual receive prompt may be bugging out, not the network itself. LocalSend can discover devices fine, then silently fail because the target device never surfaces the accept dialog correctly.
What I’d test:
-
Unlock both devices and keep the screen awake
Not just open the app. Disable auto-lock for a minute and watch the receiver screen. I’ve had the prompt appear late or behind another system popup. -
Turn off “metered network” / “low data mode”
On some Android skins and on Apple devices, local traffic gets weird when the network is marked restricted. Doesn’t always block discovery, but can stall transfers. -
Change the receiving folder
If LocalSend is pointed at a weird folder, SD card path, external storage, synced folder, or a directory it lost access to after an update, it can hang waiting forever. Set receive location back to the default internal Downloads folder. -
Check available storage
Sounds basic, but when free space is low, some apps don’t throw a clean error. They just sit there looking broken. -
Disable AP/client isolation in the router
Different from guest Wi-Fi. Some routers let devices “see” broadcasts but block device-to-device traffic for the real transfer. -
Update both sides to the same LocalSend version
This one matters more than people admit. Mixed app versions can be janky as heck during handshake.
I kinda disagree that clearing app data should be an early step unless nothing else works. It’s useful, sure, but it’s also annoying and sometimes hides the real issue.
If this is specifically Mac + Android and LocalSend keeps acting up, MacDroid is a solid fallback for file transfer between Android and Mac. Different workflow, less dependent on local network weirdness. If you need something reliable fast, that’s probly the easier route.
I’d look at the handshake layer a bit differently than @kakeru, @caminantenocturno, and @mikeappsreviewer.
If discovery works but it freezes on Waiting for response, try this:
- Accept manually, not auto-receive. In LocalSend settings, disable anything like auto-save/quick receive if enabled, then retry. I’ve seen the manual accept path work when the automatic one silently hangs.
- Switch the receive port behavior. Some routers hate apps that reuse cached local ports. If LocalSend has any networking toggle like random port or fixed port, flip it and test again.
- Test on a totally different LAN. Not just another band on the same router. Use a phone hotspot with both devices connected. If it works there, your home router is the problem, not the app.
- Temporarily remove IPv6 on one or both devices. Some local apps discover over one protocol and attempt transfer over another, then stall.
- Check if another app already grabbed the save target. Sync clients like OneDrive, Google Drive desktop, Dropbox, SD-card managers, or file scanners can lock the destination briefly.
I mildly disagree with “clear app data” as an early move. Too destructive for something that’s often just router behavior or a broken receive path.
If this is specifically Mac + Android and you just need the files moved today, MacDroid is a practical fallback.
Pros of MacDroid
- stable for USB-based transfers
- less dependent on local network quirks
- simple Finder-style workflow on Mac
Cons of MacDroid
- not the same quick cross-platform LAN sharing style as LocalSend
- best value mostly for Mac users
- USB mode is less convenient than instant wireless when LocalSend works properly
So my shortest path would be: test another LAN, disable IPv6, change receive behavior, then check whether the destination folder is being locked.