fd74a3f012
* Add upstream/parent HTTP proxy support to sandbox
When the sandbox runs in an environment that requires an HTTP proxy for
outbound internet access (e.g. corporate networks), the sandbox's own
HTTP and SOCKS proxies must chain through that upstream rather than
connecting directly.
- New parent-proxy module: config resolution (explicit config falling
back to HTTP_PROXY/HTTPS_PROXY/NO_PROXY env), NO_PROXY matching with
hostname-suffix and CIDR support, and a CONNECT-tunnel helper
- HTTP proxy: direct-path CONNECT and plain requests now tunnel through
the parent when configured; NO_PROXY and loopback still bypass
- SOCKS proxy: custom connection handler routes through parent HTTP
CONNECT instead of direct net.connect()
- Config schema: new network.parentProxy field with http/https/noProxy
- Tests: unit tests for resolution/NO_PROXY/URL selection plus an e2e
tunnel test verifying requests chain through a recording parent proxy
* Address review: security fixes, net.BlockList, unify CONNECT paths
Security fixes:
- Validate destHost in openConnectTunnel to prevent CRLF injection via
SOCKS5 DOMAINNAME (allowlist bypass + credential theft vector)
- Forward reconstructed absolute-URI (not raw req.url) to parent proxy,
closing URL-parser differential bypass
- Strip hop-by-hop and proxy-authorization headers before forwarding
- Redact userinfo from parent proxy URLs in debug logs
Correctness fixes:
- Handle proxy close during CONNECT handshake (no longer hangs forever)
- Add 30s timeout and 16KB header cap on CONNECT negotiation
- Strip brackets from IPv6 URL.hostname before netConnect/tlsConnect
- Skip port-stripping for IPv6 literals in NO_PROXY entries
- Reject empty/malformed CIDR suffixes (10.0.0.0/ no longer becomes /0)
- Bracket IPv6 destHost in CONNECT authority-form
- Omit SNI servername when proxy host is an IP literal
- Anchor status-line regex (accept 2xx, reject 200 in reason-phrase)
- Extend loopback bypass to full 127/8 and v4-mapped ::ffff:127/104
Refactors:
- Replace hand-rolled CIDR matching (parseCidr/ipInCidr/bitsMatch/
expandV6, ~70 lines) with net.BlockList
- Extract generic openConnectTunnel helper; mitm and parent CONNECT
paths now share one implementation (~70 lines deduplicated)
- http-proxy.ts CONNECT handler reduced to a single try/await/pipe
block for all three routes (mitm/parent/direct)
Tests: 33 unit + 2 integration, including regression tests for each
security fix.
* Second-round review fixes: null-byte bypass, socket leaks, IPv6 CONNECT
CRITICAL:
- Block null-byte allowlist bypass: SOCKS5 DOMAINNAME is raw bytes;
'evil.com\x00.allowed.com' passed .endsWith('.allowed.com') but DNS
truncated at the null and connected to evil.com. Now validated via
isValidHost at both the SOCKS ruleset validator and filterNetworkRequest
(defence in depth).
HIGH:
- Pause socket before removing data listener in openConnectTunnel: leaving
the stream flowing meant unshift'd trailing bytes (TLS ServerHello) could
be dropped before the caller's pipe() attached.
- Abort upstream dial on client disconnect (both HTTP and SOCKS): previously
leaked in-flight sockets when the client RST'd mid-CONNECT. New dialDirect
helper gives the direct path the same 30s timeout as tunnelled paths.
- Tear down proxyReq on client close in the HTTP request handler; destroy
res on mid-stream error instead of leaving it hung.
- Parse IPv6 CONNECT targets ([::1]:443) correctly; split(':') was
returning 400 for all IPv6.
- Forward the CONNECT head buffer to upstream (pipelined TLS ClientHello
was being dropped).
MEDIUM:
- Strip bracketed IPv6 and store bare IPs in NO_PROXY as BlockList entries
so they actually match.
- Accept schemeless HTTP_PROXY (proxy.corp:3128) like curl; reject
non-http(s) schemes with a clear error.
- CONNECT is always treated as HTTPS for HTTPS_PROXY selection (was
port==443 only).
- Plain HTTP no longer falls back to HTTPS_PROXY (matches curl).
- Drop unused _port param from shouldBypassParentProxy; document that
NO_PROXY port suffixes are host-matched only.
- Add content-length to hop-by-hop strip list (TE.CL desync hardening).
- Strip headers named in Connection: per RFC 7230.
LOW:
- Use removeListener instead of removeAllListeners('close').
- Fix misleading comment in parseNoProxy CIDR branch.
Tests: +11 regression tests (null-byte, CRLF, schemeless URL, Connection
header stripping, content-length stripping).
* Third-round review: zone-ID bypass, CL header, error-on-abort race
CRITICAL:
- Block IPv6 zone-ID allowlist bypass: '::ffff:127.0.0.1%x.github.com'
passed isIP() (Node accepts dotted zone IDs), passed
.endsWith('.github.com'), then connected to 127.0.0.1 when the OS
discarded the bogus scope. isValidHost now rejects '%' outright, and
matchesDomainPattern refuses wildcard-match on IP literals as a second
layer.
Correctness:
- Revert content-length from hop-by-hop set. It's end-to-end per RFC 7230;
stripping it forced chunked encoding on all forwarded bodies, breaking
HTTP/1.0 upstreams and CL-requiring servers. Node's llhttp already blocks
the TE+CL smuggling vector this was meant to guard against.
- Attach error handler before upstream.destroy() on client-abort: the
openConnectTunnel resolver removes its own error listener, so a late RST
could fire unhandled and crash the process.
- proxyAuthHeader: catch malformed percent-encoding rather than throwing
synchronously into the SOCKS callback (decodeURIComponent('%ZZ') throws).
- SOCKS now treats all tunnels as HTTPS for parent-proxy selection (was
port==443 only), so SSH/git/etc route through HTTPS_PROXY correctly.
- dialDirect: handle 'close' event for parity with openConnectTunnel.
- NO_PROXY: parse '[v6]:port' form (bracket-strip was failing on ']' not
being last char).
- isValidHost: accept underscore for real-world DNS records (_dmarc,
_acme-challenge).
Tests: +2 regression tests for zone-ID bypass and underscore acceptance;
content-length test updated to assert preservation.
* Fourth-round review: inet_aton canonicalization, state lifecycle, response headers
MEDIUM:
- Add canonicalizeHost and apply before allowlist matching: WHATWG URL
normalizes inet_aton shorthand (127.1, 2130706433, 0x7f.0.0.1) and IPv6
compression so string comparisons agree with what getaddrinfo() will
dial. Without this, '2852039166' dodged a denylist entry for
'169.254.169.254' and obscured user prompts.
- Strip hop-by-hop headers on responses too (was request-only): prevents
upstream Proxy-Authenticate/Connection/Transfer-Encoding leaking to
the sandboxed client.
State lifecycle:
- updateConfig() now re-resolves parentProxy for consistency with config.
- reset() clears parentProxy alongside other module state.
- resolveParentProxy returns undefined when both URLs fail to parse,
rather than a husk object that logs misleadingly.
Robustness:
- Check req.socket.destroyed after filter await in the request handler
(client may have disconnected during the filter, leaking proxyReq).
- Guard res.writeHead(500) with headersSent check in the outer catch.
- SOCKS listen() now rejects on bind error instead of hanging.
- Wrap sendStatus('HOST_UNREACHABLE') in try/catch (socket-closed race).
Tests: +5 for canonicalizeHost covering inet_aton, IPv6, trailing dot.
* Apply review suggestions: dedupe ParentProxyConfig, handle password-only auth
- Import ParentProxyConfig from sandbox-config.ts instead of duplicating
the interface locally.
- proxyAuthHeader: check both username and password before returning
undefined — http://:secret@proxy is a valid URL with empty username.
Anthropic Sandbox Runtime (srt)
A lightweight sandboxing tool for enforcing filesystem and network restrictions on arbitrary processes at the OS level, without requiring a container.
srt uses native OS sandboxing primitives (sandbox-exec on macOS, bubblewrap on Linux) and proxy-based network filtering. It can be used to sandbox the behaviour of agents, local MCP servers, bash commands and arbitrary processes.
Beta Research Preview
The Sandbox Runtime is a research preview developed for Claude Code to enable safer AI agents. It's being made available as an early open source preview to help the broader ecosystem build more secure agentic systems. As this is an early research preview, APIs and configuration formats may evolve. We welcome feedback and contributions to make AI agents safer by default!
Installation
npm install -g @anthropic-ai/sandbox-runtime
Basic Usage
# Network restrictions
$ srt "curl anthropic.com"
Running: curl anthropic.com
<html>...</html> # Request succeeds
$ srt "curl example.com"
Running: curl example.com
Connection blocked by network allowlist # Request blocked
# Filesystem restrictions
$ srt "cat README.md"
Running: cat README.md
# Anthropic Sandb... # Current directory access allowed
$ srt "cat ~/.ssh/id_rsa"
Running: cat ~/.ssh/id_rsa
cat: /Users/ollie/.ssh/id_rsa: Operation not permitted # Specific file blocked
Overview
This package provides a standalone sandbox implementation that can be used as both a CLI tool and a library. It's designed with a secure-by-default philosophy tailored for common developer use cases: processes start with minimal access, and you explicitly poke only the holes you need.
Key capabilities:
- Network restrictions: Control which hosts/domains can be accessed via HTTP/HTTPS and other protocols
- Filesystem restrictions: Control which files/directories can be read/written
- Unix socket restrictions: Control access to local IPC sockets
- Violation monitoring: On macOS, tap into the system's sandbox violation log store for real-time alerts
Example Use Case: Sandboxing MCP Servers
A key use case is sandboxing Model Context Protocol (MCP) servers to restrict their capabilities. For example, to sandbox the filesystem MCP server:
Without sandboxing (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
With sandboxing (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "srt",
"args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
Then configure restrictions in ~/.srt-settings.json:
{
"filesystem": {
"denyRead": [],
"allowWrite": ["."],
"denyWrite": ["~/sensitive-folder"]
},
"network": {
"allowedDomains": [],
"deniedDomains": []
}
}
Now the MCP server will be blocked from writing to the denied path:
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'
How It Works
The sandbox uses OS-level primitives to enforce restrictions that apply to the entire process tree:
- macOS: Uses
sandbox-execwith dynamically generated Seatbelt profiles - Linux: Uses bubblewrap for containerization with network namespace isolation
Dual Isolation Model
Both filesystem and network isolation are required for effective sandboxing. Without file isolation, a compromised process could exfiltrate SSH keys or other sensitive files. Without network isolation, a process could escape the sandbox and gain unrestricted network access.
Filesystem Isolation enforces read and write restrictions:
- Read (deny-then-allow pattern): By default, read access is allowed everywhere. You can deny broad regions (e.g.,
/Users) and then re-allow specific paths within them (e.g.,.).allowReadtakes precedence overdenyRead— the opposite of write, wheredenyWritetakes precedence overallowWrite. - Write (allow-only pattern): By default, write access is denied everywhere. You must explicitly allow paths (e.g.,
.,/tmp). An empty allow list means no write access.
Network Isolation (allow-only pattern): By default, all network access is denied. You must explicitly allow domains. An empty allowedDomains list means no network access. Network traffic is routed through proxy servers running on the host:
-
Linux: Requests are routed via the filesystem over a Unix domain socket. The network namespace of the sandboxed process is removed entirely, so all network traffic must go through the proxies running on the host (listening on Unix sockets that are bind-mounted into the sandbox)
-
macOS: The Seatbelt profile allows communication only to a specific localhost port. The proxies listen on this port, creating a controlled channel for all network access
Both HTTP/HTTPS (via HTTP proxy) and other TCP traffic (via SOCKS5 proxy) are mediated by these proxies, which enforce your domain allowlists and denylists.
For more details on sandboxing in Claude Code, see:
- Claude Code Sandboxing Documentation
- Beyond Permission Prompts: Making Claude Code More Secure and Autonomous
Architecture
src/
├── index.ts # Library exports
├── cli.ts # CLI entrypoint (srt command)
├── utils/ # Shared utilities
│ ├── debug.ts # Debug logging
│ ├── settings.ts # Settings reader (permissions + sandbox config)
│ ├── platform.ts # Platform detection
│ └── exec.ts # Command execution utilities
└── sandbox/ # Sandbox implementation
├── sandbox-manager.ts # Main sandbox manager
├── sandbox-schemas.ts # Zod schemas for validation
├── sandbox-violation-store.ts # Violation tracking
├── sandbox-utils.ts # Shared sandbox utilities
├── http-proxy.ts # HTTP/HTTPS proxy for network filtering
├── socks-proxy.ts # SOCKS5 proxy for network filtering
├── linux-sandbox-utils.ts # Linux bubblewrap sandboxing
└── macos-sandbox-utils.ts # macOS sandbox-exec sandboxing
Usage
As a CLI tool
The srt command (Anthropic Sandbox Runtime) wraps any command with security boundaries:
# Run a command in the sandbox
srt echo "hello world"
# With debug logging
srt --debug curl https://example.com
# Specify custom settings file
srt --settings /path/to/srt-settings.json npm install
As a library
import {
SandboxManager,
type SandboxRuntimeConfig,
} from '@anthropic-ai/sandbox-runtime'
import { spawn } from 'child_process'
// Define your sandbox configuration
const config: SandboxRuntimeConfig = {
network: {
allowedDomains: ['example.com', 'api.github.com'],
deniedDomains: [],
},
filesystem: {
denyRead: ['~/.ssh'],
allowWrite: ['.', '/tmp'],
denyWrite: ['.env'],
},
}
// Initialize the sandbox (starts proxy servers, etc.)
await SandboxManager.initialize(config)
// Wrap a command with sandbox restrictions
const sandboxedCommand = await SandboxManager.wrapWithSandbox(
'curl https://example.com',
)
// Execute the sandboxed command
const child = spawn(sandboxedCommand, { shell: true, stdio: 'inherit' })
// Handle exit and cleanup after child process completes
child.on('exit', async code => {
console.log(`Command exited with code ${code}`)
// Cleanup when done (optional, happens automatically on process exit)
await SandboxManager.reset()
})
Available exports
// Main sandbox manager
export { SandboxManager } from '@anthropic-ai/sandbox-runtime'
// Violation tracking
export { SandboxViolationStore } from '@anthropic-ai/sandbox-runtime'
// TypeScript types
export type {
SandboxRuntimeConfig,
NetworkConfig,
FilesystemConfig,
IgnoreViolationsConfig,
SandboxAskCallback,
FsReadRestrictionConfig,
FsWriteRestrictionConfig,
NetworkRestrictionConfig,
} from '@anthropic-ai/sandbox-runtime'
Configuration
Settings File Location
By default, the sandbox runtime looks for configuration at ~/.srt-settings.json. You can specify a custom path using the --settings flag:
srt --settings /path/to/srt-settings.json <command>
Complete Configuration Example
{
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"lfs.github.com",
"api.github.com",
"npmjs.org",
"*.npmjs.org"
],
"deniedDomains": ["malicious.com"],
"allowUnixSockets": ["/var/run/docker.sock"],
"allowLocalBinding": false
},
"filesystem": {
"denyRead": ["~/.ssh"],
"allowRead": [],
"allowWrite": [".", "src/", "test/", "/tmp"],
"denyWrite": [".env", "config/production.json"]
},
"ignoreViolations": {
"*": ["/usr/bin", "/System"],
"git push": ["/usr/bin/nc"],
"npm": ["/private/tmp"]
},
"enableWeakerNestedSandbox": false,
"enableWeakerNetworkIsolation": false
}
Configuration Options
Network Configuration
Uses an allow-only pattern - all network access is denied by default.
network.allowedDomains- Array of allowed domains (supports wildcards like*.example.com). Empty array = no network access.network.deniedDomains- Array of denied domains (checked first, takes precedence over allowedDomains)network.allowLocalBinding- Allow binding to local ports (boolean, default: false)
Unix Socket Settings (platform-specific behavior):
| Setting | macOS | Linux |
|---|---|---|
allowUnixSockets: string[] |
Allowlist of socket paths | Ignored (seccomp can't filter by path) |
allowAllUnixSockets: boolean |
Allow all sockets | Disable seccomp blocking |
Unix sockets are blocked by default on both platforms.
- macOS: Use
allowUnixSocketsto allow specific paths (e.g.,["/var/run/docker.sock"]), orallowAllUnixSockets: trueto allow all. - Linux: Blocking uses seccomp filters (x64/arm64 only). If seccomp isn't available, sockets are unrestricted and a warning is shown. Use
allowAllUnixSockets: trueto explicitly disable blocking.
Filesystem Configuration
Uses two different patterns:
Read restrictions (deny-then-allow pattern) - all reads allowed by default:
filesystem.denyRead- Array of paths to deny read access. Empty array = full read access.filesystem.allowRead- Array of paths to re-allow read access within denied regions (takes precedence over denyRead). Note: this is the opposite of write, wheredenyWritetakes precedence overallowWrite.
Write restrictions (allow-only pattern) - all writes denied by default:
filesystem.allowWrite- Array of paths to allow write access. Empty array = no write access.filesystem.denyWrite- Array of paths to deny write access within allowed paths (takes precedence over allowWrite)
Path Syntax (macOS):
Paths support git-style glob patterns on macOS, similar to .gitignore syntax:
*- Matches any characters except/(e.g.,*.tsmatchesfoo.tsbut notfoo/bar.ts)**- Matches any characters including/(e.g.,src/**/*.tsmatches all.tsfiles insrc/)?- Matches any single character except/(e.g.,file?.txtmatchesfile1.txt)[abc]- Matches any character in the set (e.g.,file[0-9].txtmatchesfile3.txt)
Examples:
"allowWrite": ["src/"]- Allow write to entiresrc/directory"allowWrite": ["src/**/*.ts"]- Allow write to all.tsfiles insrc/and subdirectories"denyRead": ["~/.ssh"]- Deny read to SSH directory"denyRead": ["/Users"], "allowRead": ["."]- Deny read to all of/Users, but re-allow the current directory"denyWrite": [".env"]- Deny write to.envfile (even if current directory is allowed)
Path Syntax (Linux):
Linux currently does not support glob matching. Use literal paths only:
"allowWrite": ["src/"]- Allow write tosrc/directory"denyRead": ["/home/user/.ssh"]- Deny read to SSH directory"denyRead": ["/home"], "allowRead": ["."]- Deny read to all of/home, but re-allow the current directory
All platforms:
- Paths can be absolute (e.g.,
/home/user/.ssh) or relative to the current working directory (e.g.,./src) ~expands to the user's home directory
Other Configuration
ignoreViolations- Object mapping command patterns to arrays of paths where violations should be ignoredenableWeakerNestedSandbox- Enable weaker sandbox mode for Docker environments (boolean, default: false)enableWeakerNetworkIsolation- Allow access tocom.apple.trustd.agentin the macOS sandbox (boolean, default: false). This is needed for Go programs (gh,gcloud,terraform,kubectl, etc.) to verify TLS certificates when usinghttpProxyPortwith a MITM proxy and custom CA. Security warning: enabling this opens a potential data exfiltration vector through the trustd service.
Common Configuration Recipes
Allow GitHub access (all necessary endpoints):
{
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"lfs.github.com",
"api.github.com"
],
"deniedDomains": []
},
"filesystem": {
"denyRead": [],
"allowWrite": ["."],
"denyWrite": []
}
}
Restrict to specific directories:
{
"network": {
"allowedDomains": [],
"deniedDomains": []
},
"filesystem": {
"denyRead": ["~/.ssh"],
"allowWrite": [".", "src/", "test/"],
"denyWrite": [".env", "secrets/"]
}
}
Workspace-only filesystem access (deny reads outside the workspace):
{
"network": {
"allowedDomains": [],
"deniedDomains": []
},
"filesystem": {
"denyRead": ["/Users"],
"allowRead": ["."],
"allowWrite": ["."],
"denyWrite": []
}
}
This denies reading anything under /Users (or /home on Linux), then re-allows the current working directory. System paths (/usr, /lib, etc.) remain readable.
Common Issues and Tips
Running Jest: Use --no-watchman flag to avoid sandbox violations:
srt "jest --no-watchman"
Watchman accesses files outside the sandbox boundaries, which will trigger permission errors. Disabling it allows Jest to run with the built-in file watcher instead.
Platform Support
- macOS: Uses
sandbox-execwith custom profiles (no additional dependencies) - Linux: Uses
bubblewrap(bwrap) for containerization - Windows: Not yet supported
Platform-Specific Dependencies
Linux requires:
bubblewrap- Container runtime- Ubuntu/Debian:
apt-get install bubblewrap - Fedora:
dnf install bubblewrap - Arch:
pacman -S bubblewrap
- Ubuntu/Debian:
socat- Socket relay for proxy bridging- Ubuntu/Debian:
apt-get install socat - Fedora:
dnf install socat - Arch:
pacman -S socat
- Ubuntu/Debian:
ripgrep- Fast search tool for deny path detection- Ubuntu/Debian:
apt-get install ripgrep - Fedora:
dnf install ripgrep - Arch:
pacman -S ripgrep
- Ubuntu/Debian:
Optional Linux dependencies (for seccomp fallback):
The package includes pre-generated seccomp BPF filters for x86-64 and arm architectures. These dependencies are only needed if you are on a different architecture where pre-generated filters are not available:
gccorclang- C compilerlibseccomp-dev- Seccomp library development files- Ubuntu/Debian:
apt-get install gcc libseccomp-dev - Fedora:
dnf install gcc libseccomp-devel - Arch:
pacman -S gcc libseccomp
- Ubuntu/Debian:
macOS requires:
ripgrep- Fast search tool for deny path detection- Install via Homebrew:
brew install ripgrep - Or download from: https://github.com/BurntSushi/ripgrep/releases
- Install via Homebrew:
Development
# Install dependencies
npm install
# Build the project
npm run build
# Build seccomp binaries (requires Docker)
npm run build:seccomp
# Run tests
npm test
# Run integration tests
npm run test:integration
# Type checking
npm run typecheck
# Lint code
npm run lint
# Format code
npm run format
Building Seccomp Binaries
The pre-generated BPF filters are included in the repository, but you can rebuild them if needed:
npm run build:seccomp
This script uses Docker to cross-compile seccomp binaries for multiple architectures:
- x64 (x86-64)
- arm64 (aarch64)
The script builds static generator binaries, generates the BPF filters (~104 bytes each), and stores them in vendor/seccomp/x64/ and vendor/seccomp/arm64/. The generator binaries are removed to keep the package size small.
Implementation Details
Network Isolation Architecture
The sandbox runs HTTP and SOCKS5 proxy servers on the host machine that filter all network requests based on permission rules:
- HTTP/HTTPS Traffic: An HTTP proxy server intercepts requests and validates them against allowed/denied domains
- Other Network Traffic: A SOCKS5 proxy handles all other TCP connections (SSH, database connections, etc.)
- Permission Enforcement: The proxies enforce the
permissionsrules from your configuration
Platform-specific proxy communication:
-
Linux: Requests are routed via the filesystem over Unix domain sockets (using
socatfor bridging). The network namespace is removed from the bubblewrap container, ensuring all network traffic must go through the proxies. -
macOS: The Seatbelt profile allows communication only to specific localhost ports where the proxies listen. All other network access is blocked.
Filesystem Isolation
Filesystem restrictions are enforced at the OS level:
- macOS: Uses
sandbox-execwith dynamically generated Seatbelt profiles that specify allowed read/write paths - Linux: Uses
bubblewrapwith bind mounts, marking directories as read-only or read-write based on configuration
Default filesystem permissions:
-
Read (deny-then-allow): Allowed everywhere by default. You can deny broad regions, then re-allow specific paths within them.
allowReadtakes precedence overdenyRead.- Example:
denyRead: ["~/.ssh"]to block access to SSH keys - Example:
denyRead: ["/Users"], allowRead: ["."]to block all of/Usersexcept the workspace - Empty
denyRead: []= full read access (nothing denied)
- Example:
-
Write (allow-only): Denied everywhere by default. You must explicitly allow paths.
- Example:
allowWrite: [".", "/tmp"]to allow writes to current directory and /tmp - Empty
allowWrite: []= no write access (nothing allowed) denyWritecreates exceptions within allowed paths (deny takes precedence)
- Example:
Precedence is intentionally opposite for reads vs writes: allowRead overrides denyRead, while denyWrite overrides allowWrite. This lets you carve out readable regions within denied areas, and carve out protected regions within writable areas.
Mandatory Deny Paths (Auto-Protected Files)
Certain sensitive files and directories are always blocked from writes, even if they fall within an allowed write path. This provides defense-in-depth against sandbox escapes and configuration tampering.
Always-blocked files:
- Shell config files:
.bashrc,.bash_profile,.zshrc,.zprofile,.profile - Git config files:
.gitconfig,.gitmodules - Other sensitive files:
.ripgreprc,.mcp.json
Always-blocked directories:
- IDE directories:
.vscode/,.idea/ - Claude config directories:
.claude/commands/,.claude/agents/ - Git hooks and config:
.git/hooks/,.git/config
These paths are blocked automatically - you don't need to add them to denyWrite. For example, even with allowWrite: ["."], writing to .bashrc or .git/hooks/pre-commit will fail:
$ srt 'echo "malicious" >> .bashrc'
/bin/bash: .bashrc: Operation not permitted
$ srt 'echo "bad" > .git/hooks/pre-commit'
/bin/bash: .git/hooks/pre-commit: Operation not permitted
Note (Linux): On Linux, mandatory deny paths only block files that already exist. Non-existent files in these patterns cannot be blocked by bubblewrap's bind-mount approach. macOS uses glob patterns which block both existing and new files.
Linux search depth: On Linux, the sandbox uses ripgrep to scan for dangerous files in subdirectories within allowed write paths. By default, it searches up to 3 levels deep for performance. You can configure this with mandatoryDenySearchDepth:
{
"mandatoryDenySearchDepth": 5,
"filesystem": {
"allowWrite": ["."]
}
}
- Default:
3(searches up to 3 levels deep) - Range:
1to10 - Higher values provide more protection but slower performance
- Files in CWD (depth 0) are always protected regardless of this setting
Unix Socket Restrictions (Linux)
On Linux, the sandbox uses seccomp BPF (Berkeley Packet Filter) to block Unix domain socket creation at the syscall level. This provides an additional layer of security to prevent processes from creating new Unix domain sockets for local IPC (unless explicitly allowed).
How it works:
-
Pre-generated BPF filters: The package includes pre-compiled BPF filters for different architectures (x64, ARM64). These are ~104 bytes each and stored in
vendor/seccomp/. The filters are architecture-specific but libc-independent, so they work with both glibc and musl. -
Runtime detection: The sandbox automatically detects your system's architecture and loads the appropriate pre-generated BPF filter.
-
Syscall filtering: The BPF filter intercepts the
socket()syscall and blocks creation ofAF_UNIXsockets by returningEPERM. This prevents sandboxed code from creating new Unix domain sockets. -
Two-stage application using apply-seccomp binary:
- Outer bwrap creates the sandbox with filesystem, network, and PID namespace restrictions
- Network bridging processes (socat) start inside the sandbox (need Unix sockets)
- apply-seccomp binary applies the seccomp filter via
prctl() - apply-seccomp execs the user command with seccomp active
- User command runs with all sandbox restrictions plus Unix socket creation blocking
Security limitations: The filter only blocks socket(AF_UNIX, ...) syscalls. It does not prevent operations on Unix socket file descriptors inherited from parent processes or passed via SCM_RIGHTS. For most sandboxing scenarios, blocking socket creation is sufficient to prevent unauthorized IPC.
Zero runtime dependencies: Pre-built static apply-seccomp binaries and pre-generated BPF filters are included for x64 and arm64 architectures. No compilation tools or external dependencies required at runtime.
Architecture support: x64 and arm64 are fully supported with pre-built binaries. Other architectures are not currently supported. To use sandboxing without Unix socket blocking on unsupported architectures, set allowAllUnixSockets: true in your configuration.
Violation Detection and Monitoring
When a sandboxed process attempts to access a restricted resource:
- Blocks the operation at the OS level (returns
EPERMerror) - Logs the violation (platform-specific mechanisms)
- Notifies the user (in Claude Code, this triggers a permission prompt)
macOS: The sandbox runtime taps into macOS's system sandbox violation log store. This provides real-time notifications with detailed information about what was attempted and why it was blocked. This is the same mechanism Claude Code uses for violation detection.
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog
Linux: Bubblewrap doesn't provide built-in violation reporting. Use strace to trace system calls and identify blocked operations:
# Trace all denied operations
strace -f srt <your-command> 2>&1 | grep EPERM
# Trace specific file operations
strace -f -e trace=open,openat,stat,access srt <your-command> 2>&1 | grep EPERM
# Trace network operations
strace -f -e trace=network srt <your-command> 2>&1 | grep EPERM
Advanced: Bring Your Own Proxy
For more sophisticated network filtering, you can configure the sandbox to use your own proxy instead of the built-in ones. This enables:
- Traffic inspection: Use tools like mitmproxy to inspect and modify traffic
- Custom filtering logic: Implement complex rules beyond simple domain allowlists
- Audit logging: Log all network requests for compliance or debugging
Example with mitmproxy:
# Start mitmproxy with custom filtering script
mitmproxy -s custom_filter.py --listen-port 8888
Note: Custom proxy configuration is not yet supported in the new configuration format. This feature will be added in a future release.
Important security consideration: Even with domain allowlists, exfiltration vectors may exist. For example, allowing github.com lets a process push to any repository. With a custom MITM proxy and proper certificate setup, you can inspect and filter specific API calls to prevent this.
Security Limitations
- Network Sandboxing Limitations: The network filtering system operates by restricting the domains that processes are allowed to connect to. It does not otherwise inspect the traffic passing through the proxy and users are responsible for ensuring they only allow trusted domains in their policy.
- Privilege Escalation via Unix Sockets: The
allowUnixSocketsconfiguration 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.sockthis 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. - Filesystem Permission Escalation: Overly broad filesystem write permissions can enable privilege escalation attacks. Allowing writes to directories containing executables in
$PATH, system configuration directories, or user shell configuration files (.bashrc,.zshrc) can lead to code execution in different security contexts when other users or system processes access these files. - Linux Sandbox Strength: The Linux implementation provides strong filesystem and network isolation but includes an
enableWeakerNestedSandboxmode that enables it to work inside of Docker environments without privileged namespaces. This option considerably weakens security and should only be used incases where additional isolation is otherwise enforced. - Weaker Network Isolation (macOS): The
enableWeakerNetworkIsolationoption re-enables access tocom.apple.trustd.agent, which is needed for Go programs to verify TLS certificates via the macOS Security framework. This opens a potential data exfiltration vector through the trustd service and should only be enabled when Go TLS verification is required (e.g., when usinghttpProxyPortwith a MITM proxy and custom CA).
Known Limitations and Future Work
Linux proxy bypass: Currently uses environment variables (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY) to direct traffic through proxies. This works for most applications but may be ignored by programs that don't respect these variables, leading to them being unable to connect to the internet.
Future improvements:
-
Proxychains support: Add support for
proxychainswithLD_PRELOADon Linux to intercept network calls at a lower level, making bypass more difficult -
Linux violation monitoring: Implement automatic
strace-based violation detection for Linux, integrated with the violation store. Currently, Linux users must manually runstraceto see violations, unlike macOS which has automatic violation monitoring via the system log store