Preflight Checklist
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:
- Docker socket = root access — Anyone with access to
/var/run/docker.sock can mount the host filesystem and execute arbitrary commands as root
- Other dangerous sockets exist — SSH agent sockets, D-Bus (
/run/user/*/bus), X11 sockets all pose similar risks
- Users don't know which sockets are dangerous — The configuration accepts any socket path without validation or warning
- 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
-
Default-deny for Unix sockets — Require explicit socket paths rather than accepting any socket. Users must understand what they're enabling.
-
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.
-
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]
-
Require explicit socket paths — Remove or deprecate blanket allowUnixSockets: true in favor of explicit path arrays:
"allowUnixSockets": ["/path/to/specific.sock"]
-
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
- Developer wants Claude Code to interact with Docker containers
- Follows official settings documentation which shows
docker.sock as an example
- Adds
/var/run/docker.sock to allowUnixSockets
- Believes sandbox still protects against malicious operations
- Malicious prompt injection runs:
docker run -v /:/host alpine cat /host/etc/shadow
- 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.
Preflight Checklist
Problem Statement
The sandboxing documentation explicitly warns that
allowUnixSocketscan lead to complete sandbox bypass:This is a security gap because:
/var/run/docker.sockcan mount the host filesystem and execute arbitrary commands as root/run/user/*/bus), X11 sockets all pose similar risks/var/run/docker.sockas the example forallowUnixSockets, normalizing the most dangerous possible configurationThe current approach puts full security responsibility on users who may not understand Unix socket security implications.
Proposed Solution
Default-deny for Unix sockets — Require explicit socket paths rather than accepting any socket. Users must understand what they're enabling.
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 busSSH_AUTH_SOCK)Provide a
--allow-dangerous-socketsflag or similar for users who understand the risks.Runtime warning for dangerous sockets — When a user configures a known-dangerous socket, display a prominent warning:
Require explicit socket paths — Remove or deprecate blanket
allowUnixSockets: truein favor of explicit path arrays: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:
docker.sock)Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
docker.sockas an example/var/run/docker.socktoallowUnixSocketsdocker run -v /:/host alpine cat /host/etc/shadowWith this feature:
Additional Context
Documentation evidence:
The warning exists in sandboxing.md (line 179):
The ironic example — Settings documentation (line 293-294) uses the dangerous socket as the example:
This normalizes the exact configuration the security documentation warns against.
Dangerous socket patterns:
/var/run/docker.sock/run/user/*/bus$SSH_AUTH_SOCK/tmp/.X11-unix/*Related security principle: Defense in depth requires the sandbox to fail safely, not silently allow bypass through configuration.