Claude Desktop update breaks LAN SSH/network access (OPERON_SANDBOXED_NETWORK=1)

Description

After a Claude Desktop update (March 23, 2026), all local network access from Claude Code running inside Claude Desktop is blocked. SSH, SCP, ping, curl to LAN hosts all fail with "No route to host". This was working fine before the update.

Environment

• Claude Desktop on macOS (Darwin 25.3.0, Apple Silicon)
• Claude Code running inside Claude Desktop (CLAUDE_CODE_ENTRYPOINT=claude-desktop)
• LAN subnet: 192.168.10.x
• Local IP: 192.168.10.62 (en0, correct subnet)
• Target host: 192.168.10.216 (Mac Mini on same subnet)

Symptoms

• ping 192.168.10.216 → "No route to host"
• ssh hosmera@192.168.10.216 → "No route to host"
• curl http://192.168.10.216:5050/ → connection refused
• nc -z 192.168.10.216 22 → fails
• Same commands from a regular terminal work fine
• ARP entry exists and is valid
• Route table is correct (route get shows proper interface)

Root cause

New environment variable OPERON_SANDBOXED_NETWORK=1 is set in Claude Code's process environment when launched from Claude Desktop. This was not present before the update. Unsetting it in the shell doesn't help — the restriction appears to be enforced at the macOS sandbox profile level.

Impact

This breaks any workflow that involves deploying code to local servers, SSHing into local machines, or interacting with LAN services. In our case, we use SSH/SCP to deploy a Flask app to a production Mac Mini on the local network — a workflow that's been working for weeks.

Expected behavior

Claude Code running inside Claude Desktop should be able to reach hosts on the local network, as it did before this update. At minimum, there should be a user-facing setting to allow LAN access.

Workaround

Run Claude Code from the CLI (claude command in terminal) instead of Claude Desktop — the CLI does not have the network sandbox.