[FEATURE] Add security guardrails for Unix socket access in sandbox

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The sandboxing documentation explicitly warns that allowUnixSockets can lead to complete sandbox bypass:

"The allowUnixSockets configuration can inadvertently grant access to powerful system services that could lead to sandbox bypasses. For example, if it is used to allow access to /var/run/docker.sock this would effectively grant access to the host system through exploiting the docker socket." — sandboxing.md

This is a security gap because:

1. Docker socket = root access — Anyone with access to /var/run/docker.sock can mount the host filesystem and execute arbitrary commands as root
2. Other dangerous sockets exist — SSH agent sockets, D-Bus (/run/user/*/bus), X11 sockets all pose similar risks
3. Users don't know which sockets are dangerous — The configuration accepts any socket path without validation or warning
4. Documentation irony — The settings documentation uses /var/run/docker.sock as the example for allowUnixSockets, normalizing the most dangerous possible configuration

The current approach puts full security responsibility on users who may not understand Unix socket security implications.

Proposed Solution

1. Default-deny for Unix sockets — Require explicit socket paths rather than accepting any socket. Users must understand what they're enabling.

1. Built-in blocklist with override — Block known-dangerous sockets by default:

• /var/run/docker.sock — Docker daemon (root access)
• /run/docker.sock — Docker daemon (alternative path)
• /run/user/*/bus — D-Bus session bus
• SSH agent sockets (SSH_AUTH_SOCK)

Provide a --allow-dangerous-sockets flag or similar for users who understand the risks.

1. Runtime warning for dangerous sockets — When a user configures a known-dangerous socket, display a prominent warning:

``
⚠️ Security Warning: /var/run/docker.sock grants root-equivalent access to
the host system. The sandbox cannot protect against Docker socket access.
Are you sure? [y/N]
``

1. Require explicit socket paths — Remove or deprecate blanket allowUnixSockets: true in favor of explicit path arrays:

``json
"allowUnixSockets": ["/path/to/specific.sock"]
``

1. Socket access audit logging — Log all Unix socket access attempts with the socket path and operation for security review.

Alternative Solutions

rnative Solutions

Current behavior: Users are responsible for understanding which sockets are dangerous. Documentation warns but doesn't prevent.

Why this is insufficient:

• Most users don't read security documentation before configuring settings
• The official example uses the most dangerous socket (docker.sock)
• Unix socket security is specialized knowledge not all developers have
• A sandbox bypass silently defeats the entire sandboxing feature

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

1. Developer wants Claude Code to interact with Docker containers
2. Follows official settings documentation which shows docker.sock as an example
3. Adds /var/run/docker.sock to allowUnixSockets
4. Believes sandbox still protects against malicious operations
5. Malicious prompt injection runs: docker run -v /:/host alpine cat /host/etc/shadow
6. Host system is fully compromised despite "sandboxing" being enabled

With this feature:

• Step 3 would trigger a security warning explaining the implications
• User could still proceed but would be informed about the tradeoff
• Security teams could audit logs for dangerous socket access
• Default configuration would be safe without explicit opt-in

Additional Context

Documentation evidence:

The warning exists in sandboxing.md (line 179):

* Privilege Escalation via Unix Sockets: The `allowUnixSockets` configuration can
  inadvertently grant access to powerful system services that could lead to sandbox
  bypasses. For example, if it is used to allow access to `/var/run/docker.sock`
  this would effectively grant access to the host system through exploiting the
  docker socket. Users are encouraged to carefully consider any unix sockets that
  they allow through the sandbox.

The ironic example — Settings documentation (line 293-294) uses the dangerous socket as the example:

"network": {
  "allowUnixSockets": ["/var/run/docker.sock"]
}

This normalizes the exact configuration the security documentation warns against.

Dangerous socket patterns:

| Socket | Risk | Common Use |
|--------|------|------------|
| /var/run/docker.sock | Root access via container escape | Container management |
| /run/user/*/bus | Desktop session hijacking | D-Bus communication |
| $SSH_AUTH_SOCK | SSH key access | SSH agent forwarding |
| /tmp/.X11-unix/* | Display capture, keylogging | X11 forwarding |

Related security principle: Defense in depth requires the sandbox to fail safely, not silently allow bypass through configuration.