[BUG] recent seccomp change for /sandbox broke executing Windows tools from WSL

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?

(I had Claude Code generate the description because it seems to have a better grasp on it that I have.)

Since approximately v2.1.92 (changelog mentions "ships the apply-seccomp helper, restoring unix-socket blocking for sandboxed commands"), the sandbox completely breaks execution of all Windows executables (.exe) from within WSL2.

WSL interop uses a Unix socket at /run/WSL/*_interop to bridge Linux-Windows process execution. The new seccomp filter blocks connect() on Unix sockets, which prevents any .exe from launching - not just those that access the network.

Steps to Reproduce

1. Run Claude Code in WSL2
2. Enable sandbox (/sandbox - enabled)
3. Try running any Windows executable:

``
cmd.exe /c "echo hello"
``

Expected Behavior

cmd.exe prints hello (worked in versions prior to ~2.1.92).

Actual Behavior

<3>WSL (22 - ) ERROR: UtilConnectUnix:524: socket failed 1

Every Windows executable fails with this error. This includes:

• cmd.exe /c "echo hello" (no network involved)
• svn.exe --version --quiet (no network involved)
• svn.exe status (local-only operation)
• Any .exe at all

Impact

This is a complete break for WSL2 users who rely on Windows-side tools. Common use cases:

• Subversion users: svn.exe (Windows) must be used instead of Linux svn to avoid working copy corruption on NTFS mounts. All svn.exe operations fail, including purely local ones like status and diff.
• Build systems: Many projects use .cmd build scripts invoked via cmd.exe. These all fail.
• Any Windows CLI tool: No Windows executable can be called from the sandbox.

Workarounds Attempted

• Adding /run/WSL to sandbox.filesystem.allowRead in settings.json - no effect (blocked at syscall level, not filesystem level)
• Adding /run/WSL/ to sandbox.filesystem.allowWrite - no effect (same reason)
• Only workaround is disabling the sandbox entirely (/sandbox - disabled)

Suggested Fix

The seccomp filter should either:

1. Allow connect() on AF_UNIX sockets specifically to the WSL interop socket path (/run/WSL/*_interop), or
2. Provide a configuration option (e.g. sandbox.allowUnixSockets: true or sandbox.allowWslInterop: true) to opt out of Unix socket blocking on WSL2, or
3. Auto-detect WSL2 and skip Unix socket blocking (since WSL interop is fundamental to the platform)

Environment

• Claude Code version: 2.1.96 (issue started around 2.1.92)
• Platform: WSL2 on Windows
• WSL kernel: 6.6.87.2-microsoft-standard-WSL2
• Distro: Ubuntu 24.04.3 LTS
• bubblewrap: 0.9.0
• Sandbox mode: enabled (with auto-allow for bash commands)

What Should Happen?

cmd.exe prints hello (worked in versions prior to ~2.1.92).

Error Messages/Logs

<3>WSL (22 - ) ERROR: UtilConnectUnix:524: socket failed 1

Steps to Reproduce

1. Run Claude Code in WSL2
2. Enable sandbox (/sandbox - enabled)
3. Try running any Windows executable:

``
cmd.exe /c "echo hello"
``

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.96

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

In case it matters: I am using Ubuntu under WSL:

uname -r && cat /proc/version 2>/dev/null | head -1

6.6.87.2-microsoft-standard-WSL2
Linux version 6.6.87.2-microsoft-standard-WSL2 (root@439a258ad544) (gcc (GCC) 11.2.0, GNU ld
(GNU Binutils) 2.37) #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025