[BUG] Claude Code CLI/Bash tool cannot access LAN devices on macOS — missing Info.plist/NSLocalNetworkUsageDescription, recurring across 5+ closed/locked issues, never fixed

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

This is a recurring, already well-diagnosed issue — please do not auto-close as stale again
This exact bug has already been independently reported and root-caused multiple times, and each report gets auto-closed by the stale-bot after ~30 days of inactivity without an actual fix ever shipping:

#27828 — closed as "not planned" (locked)
#54313 — closed as duplicate of #27828 (locked)
#47040 — closed as "not planned" (locked)
Also referenced in that history: #34402, #36675, #37326, #29541, #56433
Multiple independent users, on different Macs/macOS versions, over several months, have traced this to the exact same root cause. Filing again because all prior threads are now locked and can no longer be commented on, and the underlying bug is still present as of Claude Code CLI/extension version 2.1.199 on macOS 26.5.1.

Summary
The Bash tool (both the VS Code extension and, per other reports, the Desktop/CLI wrapper) cannot reach any device on the user's local LAN (e.g. 192.168.1.x) — ping/ssh/any socket connection to a LAN IP fails immediately with sendto: No route to host / EHOSTUNREACH. Only the default gateway and internet destinations are reachable. Confirmed not a network/router/account issue: the identical command from the same Mac, same user, in Terminal.app or via Safari works perfectly and instantly.

Root cause (confirmed independently by multiple reporters, including this one)
The native claude binary is a bare Mach-O executable, not packaged inside a proper .app bundle (Info.plist=not bound per codesign -dvvv). macOS's Local Network privacy system (TCC) requires a valid bundle identifier + an NSLocalNetworkUsageDescription key in Info.plist to:

show the permission prompt to the user at all, and
register a manageable entry in System Settings → Privacy & Security → Local Network.
Without it, the permission check silently fails closed (bundle_id: (null) / allowed: 0 in nehelper/UserEventAgent logs — see log evidence in #27828 and my own reproduction below), with no UI path for the user to ever grant access. This is independent of the OS-level network config, router, firewall, VPN, or user account — verified exhaustively in this report and in the prior linked issues.

One prior investigator (#54313) also found that even after manually patching in NSLocalNetworkUsageDescription and re-signing, the prompt still doesn't fire, because Apple's Local Network prompt is only triggered by Network.framework (nw_connection_*) calls — not by the POSIX connect() calls used by most CLI tools (curl, node, ssh, etc.). So the real fix needs both:

Ship NSLocalNetworkUsageDescription (and ideally com.apple.security.network.client) in a proper .app-bundled Info.plist for the claude binary, and
Have the binary make one explicit Network.framework call (e.g. nw_path_monitor or nw_connection_start to any LAN-scoped target) early at startup, so macOS actually surfaces the permission prompt and registers the bundle in the Local Network list.
My own reproduction (independent confirmation, 2026-07-05)
Environment: Claude Code VS Code extension 2.1.199, macOS 26.5.1 (Build 25F80), Mac mini M4
Process tree traced: zsh → .../anthropic.claude-code-2.1.199-darwin-arm64/resources/native-binary/claude → Code Helper (Plugin) → VS Code
codesign -dvvv on the claude binary: Identifier=com.anthropic.claude-code, Authority=Developer ID Application: Anthropic PBC (Q6L2SF6YDW), hardened runtime, Info.plist=not bound
Entitlements: no App Sandbox, no network entitlements (consistent with non-sandboxed process)
log stream at the moment of a failing ping showed the Local Network subsystem actively inspecting the process
Ruled out first: router AP/client isolation, target/router firewalls, macOS Application Firewall (disabled), pf (globally disabled), VPN/MDM/Screen Time (none present), Docker Desktop daemons, both Wi-Fi and wired Ethernet (identical failure on each), full macOS network-preferences reset (x2 + reboot), toggling the visible "Visual Studio Code" Local Network entries, tccutil reset All com.microsoft.VSCode, and a full VS Code uninstall + fresh reinstall — none of it changed the outcome, consistent with the bundle-identity root cause above (there was never a real permission entry for this specific unbundled binary to begin with).
Confirmed working from the exact same Mac/user/network via Terminal.app (SSH + ping, 40+ packets, sub-2ms) and via Safari (real HTTP responses from the target's nginx server) — proving the network, router, and Mac are not at fault.
Impact
Affects any Claude Code user on macOS trying to use the Bash tool to reach LAN-only infrastructure: home servers, Raspberry Pis, internal dev/staging boxes, NAS, MCP servers on private IPs, etc. The failure mode (No route to host) is indistinguishable from a real network/firewall problem, so affected users burn significant time debugging their own network before finding this is a Claude Code packaging bug — as documented across all the linked issues above.

Ask
Please reopen/unlock or link this to an actively tracked internal ticket rather than letting the stale-bot close it again — this has now been independently reported and root-caused at least 5+ times over several months with no fix shipped. Suggested fix is described above (bundle + NSLocalNetworkUsageDescription + an early Network.framework call to trigger the permission prompt).

What Should Happen?

Claude Code's Bash tool should be able to reach LAN devices (ping/ssh) just like any other process on the same Mac/user account already can (confirmed working via Terminal.app and Safari).

Error Messages/Logs

ping: sendto: No route to host
PING 192.168.1.205 (192.168.1.205): 56 data bytes
Request timeout for icmp_seq 0

--- 192.168.1.205 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

ssh: connect to host 192.168.1.205 port 22: No route to host

UserEventAgent: [com.apple.networkextension:] LocalNetwork: found bundle id com.microsoft.VSCode by PID
UserEventAgent: [com.apple.networkextension:] LocalNetwork: found bundle id com.microsoft.VSCode by UUID <...>

Steps to Reproduce

1. On macOS, use Claude Code (VS Code extension) with the Bash tool
2. Run ping <LAN IP> or ssh user@<LAN IP> for any device on the local subnet
3. Observe: ping: sendto: No route to host, immediate failure (not a timeout)
4. From the same Mac, same user account, run the identical command in Terminal.app → works perfectly

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.199

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_