"No route to host" only for the AI agent: macOS Local Network privacy

·4 mins

My coding agent couldn’t reach anything on my home network:

nc: connectx to 192.168.0.2 port 22 (tcp) failed: No route to host
ping: sendto: No route to host

The router answered, and arp -an listed the server’s MAC address. In my own Terminal, the same ssh command connected. If you see this on a Mac and only your agent sees it, your network is fine. macOS is blocking the app the agent runs in because that app doesn’t have the Local Network permission.

The setup

  • macOS 27 on Wi-Fi
  • Claude Code in its VS Code extension, so every command the agent runs is a child process of VS Code
  • Targets on the Mac’s own subnet: a Linux server, a NAS, a second router

What went wrong

The agent was helping me with a server that really was down (that story is here ). It probed the subnet from the Mac, found that only the router answered, and reported with confidence that “the Mac reaching only [the router] looks like client isolation on the Wi-Fi. That’s usually a guest network.” It told me to join a different network.

I wasn’t on a guest network, and I said so. The agent looked again and noticed what rules the network out: ping itself failed with sendto: No route to host. That message comes from the local sendto() call, so the Mac refused to send the packet at all. Client isolation drops packets in the access point, and then ping reports Request timeout, not a send error. The target’s MAC was already in the ARP table, so the kernel knew exactly where to send it.

So the block was at the MAC, and every TCP test the agent ran from there was worthless.

Later that evening, in a new session, it happened again with a different host on the same subnet. This time the agent suspected its own sandbox and retried with the sandbox off. Same error. What settled it was my reply: the same ssh command works in my Terminal.

Fix

Open System Settings → Privacy & Security → Local Network and turn on Visual Studio Code (or whichever app hosts your agent). The agent’s next ssh went through. If yours still fails, restart the app.

The app can be missing from the list if macOS never showed it the permission prompt. Apple’s TN3179 notes that the prompt doesn’t appear when a very short-lived process makes the request, and most agent commands exit right after they fail. Since macOS 27.2, the list includes a + button to add an app yourself.

Why only the agent

Local Network privacy covers traffic to addresses on a Wi-Fi or Ethernet network that goes directly to the host, not through a router. TN3179 lists who gets access without asking:

  • daemons started by launchd
  • programs running as root
  • “command-line tools run from Terminal or over SSH, including any child processes they spawn”

Everything else is charged to its “responsible code”. If an app spawns a helper and the helper connects to a local address, macOS checks the app’s permission. The agent’s shell is a child of VS Code, so ssh, nc, and ping run there under VS Code’s permission. The same binary, run by the same user from Terminal, is allowed.

That explains the other half of the symptom. Internet traffic goes through the router, so it isn’t local and works fine. TN3179 also exempts the device’s DNS server when it sits on the local network, and a home router is usually the DNS server it hands out by DHCP. That is probably why the router was the one host still reachable, and it is exactly how client isolation looks from the inside.

The same trap waits for any agent or tool that an app such as an IDE starts on macOS.

Check before you blame the network

  1. Run ping from the agent’s shell. sendto: No route to host for a host on your subnet whose MAC is in arp -an means the Mac refused to send it.
  2. Run the same command in Terminal. If it works there, check the app’s Local Network permission.
  3. If it fails in Terminal too, the cause is the network or the routing table. Later that same evening, another VPN came up as utun6 and took the default route, which cut the whole Mac off from the subnet. This time the agent caught it in netstat -rn -f inet.

Takeaway

On macOS, an app without the Local Network permission gets No route to host for hosts on your subnet, and so does every tool it spawns. An agent running inside that app will diagnose a working network as broken.

If your agent runs inside an app on macOS, open Privacy & Security → Local Network now and check that the app is on the list and switched on.