Claude Desktop 1.3561.0: SSH remote workspaces blocked on LAN — OPERON_SANDBOXED_NETWORK=1 hardcoded with no opt-out

Summary

After updating Claude Desktop from 1.3109.0 → 1.3561.0 (released ~2026-04-20), all SSH remote workspaces (/ssh:user@host:/path/...) targeting RFC1918 / LAN addresses fail immediately with connect EHOSTUNREACH. The same SSH connection succeeds instantly from the system shell, and from any subprocess Claude spawns via the Bash tool — so this is not an OS-level network issue.

Root cause is a hardcoded sandbox default in the new build with no user-facing opt-out.

Environment

• Claude Desktop: 1.3561.0 (regressed from 1.3109.0, which worked fine)
• OS: macOS (Apple Silicon)
• Feature affected: SSH remote workspaces (/ssh:tr@tr:/home/tr/... paths)
• Target: 192.168.50.100:22 on the same /24 LAN as the host machine

Reproduction

1. Add an SSH remote workspace pointing at any LAN host, e.g. /ssh:[email protected]:/path or /ssh:[email protected]:/path.
2. Try to use it (start a session, send a message, etc.).
3. Connection fails immediately (~10ms) with EHOSTUNREACH.

Expected

SSH remote workspaces continue to work against LAN hosts as they did in 1.3109.0.

Actual

~/Library/Logs/Claude/ssh.log:

[SSH2Connection] Resolved tr@tr -> [email protected]:22 (identityFiles: 1)
[SSH2Connection] Connecting to [email protected]:22 (agent: true, keys: 1, proxy: false, keyboard: true)
[SSH2Connection] Connection error: connect EHOSTUNREACH 192.168.50.100:22 - Local (192.168.50.195:51510)
[RemoteServerController] Connection failed (16ms, trigger: send_message): connect EHOSTUNREACH 192.168.50.100:22 - Local (192.168.50.195:51510)

Meanwhile, from the same machine, same shell session, same target:

$ ping -c 3 192.168.50.100   # 0% loss, ~4ms
$ nc -zv 192.168.50.100 22   # succeeded
$ ssh -v 192.168.50.100      # Connection established

And from a Node subprocess spawned by Claude's own Bash tool:

require('net').createConnection({host:'192.168.50.100',port:22})
  .on('connect', ()=>console.log('OK'))   // → OK

So the OS routes traffic fine. The block is inside Claude Desktop's main process.

Root cause

OPERON_SANDBOXED_NETWORK is now hardcoded to "1" as a default in the 1.3561.0 build (string found in /Applications/Claude.app/Contents/Resources/app.asar):

(Mat = process.env).OPERON_SANDBOXED_NETWORK ??= "1"

The flag is checked in several places, including the surface tag:

function z2A() {
  return process.env.OPERON_SURFACE
    ?? (process.env.OPERON_SANDBOXED_NETWORK === "1" ? "operon-desktop" : "operon-cli")
}

But the actual network enforcement appears to be at a deeper layer (Chromium network.mojom.NetworkService helper has its own Seatbelt sandbox: --service-sandbox-type=network --seatbelt-client=...). SSH2Connection and RemoteServerController run in the main process and route through that helper, so they get blocked.

Subprocesses spawned via the Bash tool live outside that helper's sandbox, which is why they connect fine.

No opt-out exists

I grepped every OPERON_* env var referenced in the binary. The only sandbox-related one is OPERON_SANDBOXED_NETWORK itself, which is a binary on/off:

OPERON_SANDBOXED_NETWORK
OPERON_SURFACE
(no OPERON_ALLOW_*, OPERON_NETWORK_*, allowedHost, allowLAN, etc.)

Launching with OPERON_SANDBOXED_NETWORK=0 open -a Claude correctly propagates the override (verified: echo $OPERON_SANDBOXED_NETWORK from a Bash tool call returns 0), and shell subprocesses can reach the LAN. But SSH2Connection still fails with EHOSTUNREACH — confirming the env var alone doesn't disable the network-helper sandbox.

There is also no toggle in Settings for "allow local network access" / "disable network sandbox".

Requested fix

One of:

1. Allow-list mechanism for trusted LAN destinations (per-host or per-CIDR), surfaced in Settings or as an env var like OPERON_ALLOWED_HOSTS=192.168.50.0/24.
2. Settings toggle to disable the network sandbox entirely (with a clear warning).
3. Honor OPERON_SANDBOXED_NETWORK=0 consistently — including in the network-helper sandbox profile — so the existing env var actually works.

At minimum: document that LAN access is intentionally blocked starting in 1.3561.0, and that the only workarounds are (a) downgrade, (b) standalone claude CLI, or (c) tunnel via a non-RFC1918 address (Tailscale, etc.).

Workarounds (for anyone hitting this in the meantime)

• Downgrade to 1.3109.0 and disable auto-update.
• Use the standalone claude CLI from a terminal — no Operon sandbox, LAN works.
• Put the remote host on Tailscale / Cloudflare Tunnel and SSH to its 100.x / public address (the block appears specific to RFC1918).