Since the latest Cursor update (3.2.11), the integrated terminal can no longer reach local network devices (e.g. ESP32 at 192.168.4.1). All connections fail with errno 65: No route to host. This was working fine on the previous version. The same commands (ping, TCP connect, Python scripts) still work from Terminal.app.
Root cause: Cursor’s Info.plist does not include the NSLocalNetworkUsageDescription key. Without it, macOS silently blocks all local network access from the app and its child processes, and never shows a permission prompt. The app also never appears in System Settings > Privacy & Security > Local Network, so users cannot grant the permission manually.
It appears this key was either present in a previous build or the entitlement/signing changed in a way that revoked a previously granted Local Network permission.
Steps to Reproduce
Connect to a local network device (e.g. an ESP32 SoftAP at 192.168.4.1)
From Cursor’s integrated terminal: ping 192.168.4.1 → fails with “No route to host”
From Terminal.app: ping 192.168.4.1 → works
Expected Behavior
Cursor should prompt for Local Network permission and allow access when granted, as it did before the update.
Upstream VS Code added this key in early April, but the change hasn’t landed in Cursor yet. I’ve reported it internally as a build bug, no timeline for the fix yet.
A workaround that sometimes helps, but not for everyone, is to toggle the Local Network permission for any other app in System Settings > Privacy & Security > Local Network. macOS re-reads permissions and sometimes lets Cursor through. There’s no permanent solution yet, we need the plist key in a signed build.
Once the fix ships to stable, we’ll reply in this thread.
Problem
Cursor’s terminal cannot reach any local network host (192.168.x.x) while internet connectivity works fine. Error returned:
nc: connectx to 192.168.1.55 port 22 (tcp) failed: No route to host
ping: sendto: No route to host
SSH to the same host works perfectly from macOS native Terminal.app.
Root Cause (confirmed)
Running codesign -d --entitlements - /Applications/Cursor.app reveals the app is missing critical network entitlements:
[Key] com.apple.security.automation.apple-events → true
[Key] com.apple.security.cs.allow-jit → true
[Key] com.apple.security.device.audio-input → true
[Key] com.apple.security.device.camera → true
Absent:
• com.apple.security.network.client — required for outbound TCP
• NSLocalNetworkUsageDescription — required for macOS Sequoia Local Network privacy prompt
Without NSLocalNetworkUsageDescription , macOS silently blocks all RFC-1918 traffic and never shows the permission dialog. The app never appears in System Settings → Privacy & Security → Local Network, making it impossible for the user to grant access manually. tccutil reset LocalNetwork also fails because there is no TCC entry to reset.
Steps to Reproduce
1. Open Cursor terminal (not agent, regular terminal)
2. Run ping -c 3 192.168.1.x to any local machine
3. Observe: No route to host — no permission dialog appears
4. Run ping github.com — works fine
5. Check System Settings → Privacy & Security → Local Network — Cursor is absent from the list
Expected Behavior
On first local network access attempt, macOS should display a permission dialog. After granting, local network hosts should be reachable from Cursor’s terminal.
Fix Required
Add to Cursor.app entitlements and Info.plist :
• com.apple.security.network.client = true
• NSLocalNetworkUsageDescription with a usage description string
Same issue on my machine. Cursor does not appear under System Settings → Privacy & Security → Local Network, so there is no toggle to enable access.
Environment
Cursor: 3.4.20 (Stable)
macOS: 26.5 (25F71), arm64
Bundle ID:com.todesktop.230313mzl4w4u92
Problem
git push to a LAN-hosted Gitea server (http://gitea.my-lan.org:3000 → 192.168.1.38) fails from Cursor’s integrated terminal and from the Agent terminal with:
`git push` to a LAN-hosted Gitea server (`http://gitea.my-lan.org:3000` → `192.168.1.38`) fails from Cursor’s integrated terminal and from the Agent terminal with:
Failed to connect … Immediate connect fail for 192.168.1.38: No route to host
External apps with Local Network permission work (e.g. IntelliJ IDEA). **Terminal.app** works after granting Local Network there (workaround).
### Root cause (verified)
`NSLocalNetworkUsageDescription` is **missing** from Cursor’s Info.plist:
Hey, thanks for confirming the bug still happens in 3.4.20. The root cause is the same, NSLocalNetworkUsageDescription is missing from Info.plist. We’re already tracking this on our side, but I can’t share an ETA yet. I’ll update this thread once the fix is in a stable build.
As a temporary workaround, toggling the Local Network permission for any other app in System Settings > Privacy & Security > Local Network helps some users. macOS sometimes lets Cursor through after that, but it doesn’t work for everyone. Since Terminal.app gets access after you grant permissions, you can use it for git push while we wait for the fix on our side.
Remote SSH fails to connect to a local network host configured with a non-standard port. Cursor resolves the hostname and IP correctly from ~/.ssh/config but the connection fails immediately (after ~10ms) with No route to host. The same host connects fine via terminal SSH.
Steps to Reproduce
Define a host in ~/.ssh/config with a non-standard SSH port (e.g. 55977) pointing to a local network IP (192.168.x.x)
Use 1Password SSH agent via IdentityAgent in the global Host * block
Open Cursor and connect to the host via Remote SSH
Connection fails immediately
Expected Behavior
Cursor should connect to the remote host the same way the terminal does when running ssh , respecting the Port directive in ~/.ssh/config.
Operating System
MacOS
Version Information
Extension: anysphere.remote-ssh-1.0.49
For AI issues: which model did you use?
N/A
For AI issues: add Request ID with privacy disabled
The failure appears specific to how Cursor invokes SSH. It appends -D 62262 (SOCKS proxy) to the SSH command, which may interact differently with local network routing compared to a plain ssh call. The No route to host error at 10ms suggests the issue is at the TCP connection level, not auth or config parsing. The SSH config and credentials are confirmed correct via successful terminal connections.
Still not fixed in 3.6.31
Neither git extension, nor terminal within cursor can access a git server in the local network. It works with external servers. MacOs is not asking for local network permission for cursor, despite “tccutil reset All com.todesktop.230313mzl4w4u92”
Thanks for the update, @SvenEwald. Yep, the bug is still happening. The root cause is the same. NSLocalNetworkUsageDescription is still missing from Info.plist, and nothing changed in 3.6.31. We’re tracking the issue, but I can’t share an exact fix timeline yet.
You’re right about tccutil reset. There’s nothing to reset since there are no TCC entries for Cursor at all, and the app doesn’t show up under Local Network.
One workaround that sometimes helps is to open System Settings > Privacy & Security > Local Network and toggle off and back on the permission for any other app in the list. macOS reloads the permissions, and Cursor sometimes starts working after that. It doesn’t work for everyone.
For git push to a LAN server, you can use Terminal.app for now. Once you grant Local Network permission there, it works.
As soon as the fix lands in a stable build, I’ll update this thread.
My consistent workaround is to use Terminal (or iTerm or whatever else) that is already able to connect to local network devices and launch Cursor from there, in case it helps anyone else:
Thanks for the workaround, @ilg0. Launching Cursor from a terminal that already has Local Network access is a really reliable workaround until the key shows up in a signed build. For anyone who finds this thread:
/Applications/Cursor.app/Contents/MacOS/Cursor &
Status is unchanged. NSLocalNetworkUsageDescription is still missing from Info.plist. We’re tracking the bug internally, and once the change lands in a stable build, we’ll reply here.
Other workarounds if launching from Terminal doesn’t work for you: toggle Local Network for any other app in System Settings > Privacy & Security > Local Network. macOS sometimes refreshes permissions and then lets Cursor through. Or use Terminal.app for git push to a LAN server.
Just updated and now local network ssh seems to be working just fine. If this isn’t an actual fix in Cursor, then the other thing that change is this: I had a window open on a project folder inside my Documents directory when the update installed, so on relaunch, I got a system prompt to allow Cursor to access my Documents directory, and allowed. When I then checked the other windows, which were ssh-remote over the local network, they had loaded successfully instead of failing like they had in the past. I probably hadn’t previously opened a project from inside my local machine Documents folder while Cursor was launched directly (as opposed to having been opened from Terminal).
Hey, thanks for the update, @ilg0. It’s good that local SSH works in 3.8.11, but it looks like this isn’t coming from our fix.
The NSLocalNetworkUsageDescription key still hasn’t been added to the signed build’s Info.plist, and there hasn’t been any status change on that. The fact that you got the system prompt for Documents access and SSH started working again most likely acted like a refresh of macOS’s permission cache. It’s the same kind of effect as toggling Local Network for another app or launching Cursor from Terminal. So this isn’t a permanent solution, and on a clean machine or after a reinstall the issue can come back.
So the bug on our side is still open, we’re tracking it, and I can’t share an ETA for a fix yet. As soon as the key shows up in a stable build, I’ll post an update here.
If local network breaks again for anyone, launching from Terminal that already has access still helps:
Hey, thanks for running the check. That clears things up.
The NSLocalNetworkUsageDescription key is still missing from Info.plist (does not exist), so the fix still hasn’t made it into the signed build. That means it “works” for some users right now, but that’s not the real fix, it’s a temporary effect. macOS re-reads the permission state after the system prompt, launching from Terminal, or toggling Local Network for another app. After a reinstall or on a clean machine, local network access will likely break again because the key isn’t in the build.
The bug on our side is still open and we’re tracking it. I can’t share an ETA yet. Once the key actually shows up in the stable build (you can verify with the same defaults read command), I’ll update the thread.