Anthropic Sandbox Runtime (srt)

Легковесный инструмент песочницы для обеспечения ограничений файловой системы и сети на произвольных процессах на уровне ОС, без необходимости контейнера.

srt использует нативные примитивы песочницы ОС (sandbox-exec на macOS, bubblewrap на Linux) и прокси-фильтрацию сети. Его можно использовать для изоляции поведения агентов, локальных MCP-серверов, bash-команд и произвольных процессов.

Бета-исследовательское превью

Sandbox Runtime — это исследовательское превью, разработанное для Claude Code для обеспечения более безопасных ИИ-агентов. Оно публикуется в качестве раннего открытого превью, чтобы помочь более широкой экосистеме создавать более безопасные агентные системы. Поскольку это раннее исследовательское превью, API и форматы конфигурации могут меняться. Мы приветствуем отзывы и вклад, чтобы сделать ИИ-агентов безопаснее по умолчанию!

Установка```bash

npm install -g @anthropic-ai/sandbox-runtime

## Базовое использование```bash
# 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

Обзор

Этот пакет предоставляет автономную реализацию песочницы, которая может использоваться и как CLI-инструмент, и как библиотека. Он спроектирован с философией безопасности по умолчанию, ориентированной на типичные сценарии разработчиков: процессы запускаются с минимальным доступом, а вы явно открываете только те отверстия, которые вам нужны.

Ключевые возможности:

Сетевые ограничения: Управление тем, какие хосты/домены могут быть доступны через HTTP/HTTPS и другие протоколы
Ограничения файловой системы: Управление тем, какие файлы/каталоги можно читать/записывать
Ограничения Unix-сокетов: Управление доступом к локальным IPC-сокетам
Мониторинг нарушений: На macOS доступ к системному хранилищу журналов нарушений песочницы для оповещений в реальном времени

Пример использования: изоляция MCP-серверов

Ключевой вариант использования — изоляция серверов Model Context Protocol (MCP) для ограничения их возможностей. Например, чтобы изолировать MCP-сервер файловой системы:

Без изоляции (.mcp.json):```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem"] } } }

**С песочницей** (`.mcp.json`):```json
{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

Затем настройте ограничения в ~/.srt-settings.json:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Теперь MCP-серверу будет запрещено записывать в запрещённый путь:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Как это работает

Песочница использует примитивы уровня ОС для применения ограничений, которые действуют на всё дерево процессов:

macOS: использует sandbox-exec с динамически генерируемыми профилями Seatbelt
Linux: использует bubblewrap для контейнеризации с изоляцией сетевых пространств имён
Windows: запускает изолированный процесс под выделенной локальной учётной записью srt-sandbox, с ограничением исходящего трафика через Windows Filtering Platform, привязанным к SID этой учётной записи и явными ACE для каждого сеанса в рабочем дереве

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Модель двойной изоляции

Для эффективной работы песочницы требуется изоляция и файловой системы, и сети. Без изоляции файловой системы скомпрометированный процесс может выкрасть SSH-ключи или другие чувствительные файлы. Без сетевой изоляции процесс может выйти из песочницы и получить неограниченный доступ к сети.

Изоляция файловой системы обеспечивает ограничения на чтение и запись:

Чтение (шаблон «сначала запрет, затем разрешение»): по умолчанию чтение разрешено везде. Вы можете запретить большие области (например, /Users), а затем повторно разрешить конкретные пути внутри них (например, .). allowRead имеет приоритет над denyRead — в отличие от записи, где denyWrite имеет приоритет над allowWrite.
Запись (шаблон «только разрешение»): по умолчанию запись запрещена везде. Вы должны явно разрешить пути (например, ., /tmp). Пустой список разрешений означает отсутствие доступа на запись.

Сетевая изоляция (шаблон «только разрешение»): по умолчанию весь сетевой доступ запрещён. Вы должны явно разрешить домены. Пустой список allowedDomains означает отсутствие сетевого доступа. Сетевой трафик маршрутизируется через прокси-серверы, работающие на хосте:

Linux: запросы маршрутизируются через файловую систему по Unix-сокету. Сетевое пространство имён изолированного процесса удаляется полностью, поэтому весь сетевой трафик должен проходить через прокси, работающие на хосте (слушающие Unix-сокеты, которые смонтированы в песочницу через bind mount)
macOS: профиль Seatbelt разрешает связь только с определённым портом localhost. Прокси слушают этот порт, создавая контролируемый канал для всего сетевого доступа
Windows: общесистемный набор фильтров WFP блокирует все исходящие соединения, исходящие от учётной записи srt-sandbox, кроме loopback-соединений к диапазону портов прокси. Прокси слушают внутри этого диапазона, создавая контролируемый канал для всего сетевого доступа

Как HTTP/HTTPS (через HTTP-прокси), так и остальной TCP-трафик (через SOCKS5-прокси) проходят через эти прокси, которые применяют ваши списки разрешённых и запрещённых доменов.

Более подробно о песочнице в Claude Code см.:

Архитектура```

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 └── windows-sandbox-utils.ts # Windows srt-win sandboxing

## Usage

### As a CLI tool

The `srt` command (Anthropic Sandbox Runtime) wraps any command with security boundaries:

---

## Использование

### Как CLI-инструмент

Команда `srt` (Anthropic Sandbox Runtime) оборачивает любую команду в границы безопасности:```bash
# 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

В качестве библиотеки```typescript

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() })

**Атрибуция нарушений (`commandId` / `commandText`).** Нарушения, наблюдаемые во время выполнения обёрнутой команды (строки журнала seatbelt, события seccomp, отказы прокси), хранятся под ключом атрибуции, и `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` ищут их по тому же ключу. По умолчанию ключом является сама обёрнутая строка. Передавайте при каждом вызове непрозрачный `commandId` (например, идентификатор вызова инструмента), чтобы использовать его в качестве ключа — рекомендуется: ключи сравниваются по первым 100 символам, поэтому длинные команды с общим префиксом иначе получили бы перекрёстную атрибуцию, а повторный запуск того же текста унаследовал бы события предыдущего запуска. Если строка, которую вы *выполняете*, не является той командой, которую *представляет* вызов (например, вы оборачиваете собранную строку `source <snapshot> && eval '<cmd>'`), также передайте `commandText: '<cmd>'`: именно с ней сопоставляются шаблоны команд `ignoreViolations`, и именно её каждое нарушение указывает в качестве своей `command`.```typescript
const wrapped = await SandboxManager.wrapWithSandbox(
  assembledCommand, // what actually runs
  undefined,
  undefined,
  undefined,
  { commandId: invocationId, commandText: rawCommand },
)
// ... run it ...
const annotated = SandboxManager.annotateStderrWithSandboxFailures(invocationId, stderr)

Доступные экспорты```typescript

// 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'

## Конфигурация

### Расположение файла настроек

По умолчанию среда выполнения песочницы ищет конфигурацию в `~/.srt-settings.json`. Вы можете указать свой путь с помощью флага `--settings`:```bash
srt --settings /path/to/srt-settings.json <command>

Полный пример конфигурации```json

{ "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, "allowAppleEvents": false }

### Параметры конфигурации

#### Сетевая конфигурация

Используется **разрешающий шаблон (allow-only pattern)** - весь сетевой доступ по умолчанию запрещён.

- `network.allowedDomains` - Массив разрешённых доменов (поддерживает подстановочные знаки, например `*.example.com`). Пустой массив = нет сетевого доступа. Необязательный суффикс `:port` (`api.example.com:443`, `*.example.com:8443`) ограничивает запись портом назначения; записи без порта соответствуют любому порту.
  - Литералы IPv6 должны быть заключены в квадратные скобки в стиле RFC 3986: `[::1]`, `[2001:db8::1]:443`. Запись с несколькими двоеточиями без скобок отклоняется как неоднозначная (`2001:db8::1:443` сама по себе является корректным адресом).
- `network.deniedDomains` - Массив запрещённых доменов (проверяется первым, имеет приоритет над allowedDomains). Действует тот же суффикс `:port`, а также допускается одиночный `*` (или `*:22`) для запрета всего.
- `network.deniedDomainReasons` - Необязательная карта (map), связывающая запись `deniedDomains` (по точному совпадению строки) с причиной, видимой модели, которая появляется в строке `<sandbox_violations>`, когда эта запись блокирует соединение - укажите, что именно заблокировано, и разрешённую альтернативу (например, `{"github.com:22": "SSH pushes to GitHub are blocked; use an https:// remote"}`). Записи без причины получают стандартную формулировку. Для SSH-адресатов (порт 22) причина также доставляется внутри канала (in-band): SSH-клиент, туннелируемый через SOCKS ProxyCommand без аутентификации (например, BSD `nc -X 5`), получает до обмена ключами SSH-разъединение, описание которого и есть причина; OpenSSH выводит это дословно — поэтому формулируйте такие причины объёмом до ~400 ASCII-символов, начиная с императива, поскольку OpenSSH обрезает и экранирует не-ASCII символы.
- `network.allowLocalBinding` - Разрешить привязку к локальным портам (boolean, по умолчанию: false)

**TLS-терминирование** (`network.tlsTerminate`, экспериментально): когда этот параметр задан, HTTPS CONNECT-запросы терминируются внутри процесса, чтобы SRT мог видеть (и фильтровать через `network.filterRequest`) расшифрованные запросы. Процесс в песочнице получает набор доверенных сертификатов, содержащий MITM CA (`caCertPath`/`caKeyPath`, или временный CA, если они не указаны), а также штатные корневые сертификаты хоста, поэтому и сертификаты, выпущенные прокси, и реальные сертификаты вышестоящего сервера проходят проверку.

- `network.tlsTerminate.excludeDomains` - Шаблоны доменов (тот же синтаксис, что и у `allowedDomains`), которые **не** терминируются. Соответствующие CONNECT-запросы вместо этого туннелируются без расшифровки (opaque): они по-прежнему подчиняются списку разрешённых доменов, однако клиент внутри песочницы сам выполняет TLS-рукопожатие с реальным вышестоящим сервером, а `filterRequest` / внедрение учётных данных к их HTTPS-трафику не применяются. Используйте это для двух случаев, в которых TLS-терминирование принципиально ломается:
  - **mTLS-апстримы (mTLS upstreams)** - только клиент внутри песочницы владеет клиентским сертификатом, поэтому прокси не может заново установить соединение от его имени.
  - **Клиенты с пиннингом сертификатов (certificate-pinning clients)** - клиенты, которые сами проверяют личность вышестоящего сервера (собственные CA, пиннинг SAN) и отклоняют MITM-сертификат.
- `network.tlsTerminate.extraCaCertPaths` - Пути к файлам PEM-сертификатов CA, добавляемым в этот набор доверенных сертификатов после MITM CA и штатных корневых сертификатов хоста. Исключённые (не терминируемые) хосты проверяются клиентом внутри песочницы, а переменные окружения доверия, задаваемые SRT (`SSL_CERT_FILE`, `GIT_SSL_CAINFO`, ...) _заменяют_ собственную конфигурацию доверия каждого инструмента, поэтому локальный корневой сертификат (например, внутренний mTLS CA) должен быть в наборе, иначе такие хосты никогда не будут проверены. В набор копируются только блоки `CERTIFICATE` из каждого файла (всё остальное, например закрытый ключ в объединённом PEM, никогда не передаётся в песочницу); файлы, которые отсутствуют, не читаются или не содержат блока PEM `CERTIFICATE`, пропускаются, поэтому можно безопасно указывать пути, существующие лишь на некоторых хостах.```json
{
  "network": {
    "allowedDomains": ["*.example.com", "internal-mtls.example.net"],
    "deniedDomains": [],
    "tlsTerminate": {
      "excludeDomains": ["internal-mtls.example.net"],
      "extraCaCertPaths": ["/etc/internal-mtls-roots.pem"]
    }
  }
}

Настройки Unix-сокетов (поведение зависит от платформы):

Setting	macOS	Linux
`allowUnixSockets: string[]`	Список разрешённых путей к сокетам	Игнорируется (seccomp не может фильтровать по пути)
`allowAllUnixSockets: boolean`	Разрешить все сокеты	Отключить блокировку seccomp

Unix-сокеты заблокированы по умолчанию на обеих платформах.

macOS: используйте allowUnixSockets, чтобы разрешить конкретные пути (например, ["/var/run/docker.sock"]), или allowAllUnixSockets: true, чтобы разрешить все.
Linux: блокировка использует фильтры seccomp (только x64/arm64). Если seccomp недоступен, сокеты не ограничиваются, и выводится предупреждение. Используйте allowAllUnixSockets: true, чтобы явно отключить блокировку.

Конфигурация файловой системы

Используются два разных шаблона:

Ограничения на чтение (шаблон «сначала запрет, затем разрешение») — по умолчанию разрешены все чтения:

filesystem.denyRead — массив путей для запрета доступа на чтение. Пустой массив = полный доступ на чтение.
filesystem.allowRead — массив путей для повторного разрешения доступа на чтение в запрещённых областях (имеет приоритет над denyRead). Примечание: это противоположность записи, где denyWrite имеет приоритет над allowWrite.

Ограничения на запись (шаблон «только разрешение») — по умолчанию все записи запрещены:

filesystem.allowWrite — массив путей для разрешения доступа на запись. Пустой массив = нет доступа на запись.
filesystem.denyWrite — массив путей для запрета доступа на запись в разрешённых путях (имеет приоритет над allowWrite)

Синтаксис путей (macOS):

На macOS пути поддерживают glob-шаблоны в стиле git, аналогично синтаксису .gitignore:

* — соответствует любым символам, кроме / (например, *.ts соответствует foo.ts, но не foo/bar.ts)
** — соответствует любым символам, включая / (например, src/**/*.ts соответствует всем .ts-файлам в src/)
? — соответствует любому одному символу, кроме / (например, file?.txt соответствует file1.txt)
[abc] — соответствует любому символу из набора (например, file[0-9].txt соответствует file3.txt)

Примеры:

"allowWrite": ["src/"] — разрешить запись во весь каталог src/
"allowWrite": ["src/**/*.ts"] — разрешить запись во все .ts-файлы в src/ и подкаталогах
"denyRead": ["~/.ssh"] — запретить чтение каталога SSH
"denyRead": ["/Users"], "allowRead": ["."] — запретить чтение всего /Users, но повторно разрешить текущий каталог
"denyWrite": [".env"] — запретить запись в файл .env (даже если текущий каталог разрешён)

Синтаксис путей (Linux):

В Linux в настоящее время не поддерживается сопоставление по glob-шаблонам. Используйте только литеральные пути:

"allowWrite": ["src/"] — разрешить запись в каталог src/
"denyRead": ["/home/user/.ssh"] — запретить чтение каталога SSH
"denyRead": ["/home"], "allowRead": ["."] — запретить чтение всего /home, но повторно разрешить текущий каталог

Все платформы:

Пути могут быть абсолютными (например, /home/user/.ssh) или относительными относительно текущего рабочего каталога (например, ./src)
~ раскрывается в домашний каталог пользователя

Прочие настройки

ignoreViolations — объект, сопоставляющий шаблоны команд с массивами путей, где нарушения должны игнорироваться
enableWeakerNestedSandbox — включает более слабый режим песочницы для сред Docker (логическое значение, по умолчанию: false)
enableWeakerNetworkIsolation — разрешает доступ к com.apple.trustd.agent в песочнице macOS (логическое значение, по умолчанию: false). Это необходимо программам на Go (gh, gcloud, terraform, kubectl и т. д.) для проверки TLS-сертификатов при использовании httpProxyPort с MITM-прокси и собственным CA. Предупреждение о безопасности: включение этой опции открывает потенциальный вектор утечки данных через службу trustd.
allowAppleEvents — разрешает отправку Apple Events и запросов открытия Launch Services из песочницы macOS (логическое значение, по умолчанию: false). Без этого такие команды, как open, osascript и всё, что открывает URL-адреса или управляет другими приложениями через AppleScript, завершаются с ошибкой AppleScript -600 («Application isn't running») или ошибками LaunchServices (-10822, -54). Предупреждение о безопасности: включение этой опции означает, что песочница больше не обеспечивает изоляцию выполнения кода. Команда в песочнице может запускать другие приложения через open без запроса пользователя, и всё, что она запускает, работает вне ограничений файловой системы и сети песочницы; автоматизация уже запущенных приложений через Apple Events дополнительно ограничивается пользовательским согласием TCC для конкретного приложения. Встраивающие решения должны брать эту опцию только из доверенной пользовательской конфигурации — никогда из файлов проекта в проверенном репозитории, поскольку атакующий проект мог бы таким образом повысить собственные права песочницы.

Распространённые рецепты конфигурации

Разрешить доступ к GitHub (все необходимые конечные точки):```json { "network": { "allowedDomains": [ "github.com", "*.github.com", "lfs.github.com", "api.github.com" ], "deniedDomains": [] }, "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] } }

**Ограничить конкретными каталогами:**```json
{
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowWrite": [".", "src/", "test/"],
    "denyWrite": [".env", "secrets/"]
  }
}

Доступ к файловой системе только в пределах рабочей области (запретить чтение за пределами рабочей области):```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

Это запрещает чтение всего, что находится в `/Users` (или `/home` в Linux), затем снова разрешает текущую рабочую директорию. Системные пути (`/usr`, `/lib` и т. д.) остаются доступными для чтения.

### Частые проблемы и советы

**Запуск Jest:** Используйте флаг `--no-watchman`, чтобы избежать нарушений песочницы:```bash
srt "jest --no-watchman"

Watchman обращается к файлам за пределами границ песочницы, что вызовет ошибки разрешений. Отключение Watchman позволяет Jest использовать встроенный файловый наблюдатель вместо него.

Поддержка платформ

macOS: Использует sandbox-exec с пользовательскими профилями (без дополнительных зависимостей)
Linux: Использует bubblewrap (bwrap) для контейнеризации
Windows: Альфа — использует встроенный помощник srt-win.exe (без дополнительных зависимостей). См. Windows (alpha) ниже для настройки, модели безопасности и известных ограничений

Платформенные зависимости

Для Linux требуется:

bubblewrap - Среда выполнения контейнеров
- Ubuntu/Debian: apt-get install bubblewrap
- Fedora: dnf install bubblewrap
- Arch: pacman -S bubblewrap
socat - Сокет-ретранслятор для прокси-моста
- Ubuntu/Debian: apt-get install socat
- Fedora: dnf install socat
- Arch: pacman -S socat
ripgrep - Быстрый инструмент поиска для обнаружения запрещённых путей
- Ubuntu/Debian: apt-get install ripgrep
- Fedora: dnf install ripgrep
- Arch: pacman -S ripgrep

Примечание для Ubuntu 24.04+: В этих выпусках параметр kernel.apparmor_restrict_unprivileged_userns включён по умолчанию, что позволяет unshare(CLONE_NEWUSER), но лишает полученное пространство имён capabilities. И bubblewrap, и слой изоляции seccomp нуждаются в пользовательских пространствах имён с capabilities. Отключите ограничение с помощью:```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

или добавьте профиль AppArmor, предоставляющий `userns` соответствующим бинарным файлам.

**Необязательные зависимости Linux (для запасного варианта с seccomp):**

Пакет включает предварительно сгенерированные seccomp BPF-фильтры для архитектур x86-64 и arm. Эти зависимости нужны только в том случае, если вы работаете на другой архитектуре, для которой предварительно сгенерированные фильтры недоступны:

- `gcc` или `clang` — C-компилятор
- `libseccomp-dev` — файлы разработки библиотеки Seccomp
  - Ubuntu/Debian: `apt-get install gcc libseccomp-dev`
  - Fedora: `dnf install gcc libseccomp-devel`
  - Arch: `pacman -S gcc libseccomp`

**Для macOS требуется:**

- `ripgrep` — быстрый инструмент поиска для обнаружения запрещённых путей
  - Установка через Homebrew: `brew install ripgrep`
  - Или загрузите с: https://github.com/BurntSushi/ripgrep/releases

**Для Windows требуется:**

- Дополнительные зависимости не нужны. Вспомогательный файл `srt-win.exe` (x64 и arm64) включён в npm-пакет. Требуется однократный шаг `windows-install` с повышенными привилегиями — см. ниже.

## Windows (альфа)

Поддержка Windows имеет статус **альфа**. Изолированный процесс выполняется под выделенной локальной учётной записью `srt-sandbox`, изолированной от вызывающего пользователя с помощью нативных примитивов безопасности Windows — брандмауэра Windows Filtering Platform (WFP), ограничивающего исходящий трафик на основе SID учётной записи песочницы, и явных ACE на уровне сессии, которые предоставляют или запрещают этому SID доступ к настроенным путям файловой системы.

### Настройка

Выполните один раз на каждой машине (самоповышение прав; одно приглашение UAC):```powershell
npx @anthropic-ai/sandbox-runtime windows-install

Это подготавливает локальную учётную запись srt-sandbox (со случайным паролем, хранящимся в зашифрованном через DPAPI виде в %LOCALAPPDATA%\sandbox-runtime\state.db), локальную группу sandbox-runtime-users и устанавливает общесистемный набор WFP-фильтров, привязанный к SID учётной записи srt-sandbox. Операция идемпотентна — повторный запуск ротирует пароль учётной записи песочницы и приводит набор фильтров в соответствие.

Выход из системы не требуется. WFP-фильтры привязаны к SID отдельной учётной записи песочницы, поэтому ваша собственная сеть, службы и любой другой субъект на машине остаются незатронутыми.

После установки SandboxManager.initialize() и CLI srt работают как на других платформах. initialize() проверяет, что учётная запись песочницы и WFP-ограждение активны, и в противном случае завершается ошибкой с практической рекомендацией.

Программная установка и удаление экспортируются как installWindowsSandbox() / uninstallWindowsSandbox().

Модель безопасности

Команда в песочнице выполняется от имени учётной записи srt-sandbox, а не от имени вызывающего пользователя. Встроенный помощник srt-win.exe выполняет двухэтапный запуск: брокер вызывает CreateProcessWithLogonW, чтобы запустить исполнитель от имени srt-sandbox, а исполнитель порождает целевой процесс с ограниченным токеном внутри объекта job. Дочерний процесс наследует изолированный профиль учётной записи песочницы (%USERPROFILE%, %TEMP%, HKCU) и новое окружение, дополненное только PATH брокера и сгенерированными переменными прокси.

Работа под отдельным пользовательским SID структурно закрывает класс обхода через порождение суррогатных процессов (Планировщик заданий, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS для процесса, принадлежащего брокеру, BITS, внепроцессный COM с RunAs="Interactive User"): любой процесс, который дочернему процессу удастся породить вне установленного канала, всё равно несёт SID srt-sandbox, поэтому остаётся под WFP-ограждением исходящего трафика и не имеет прав на файлы вызывающего пользователя.

Сетевая изоляция — это набор WFP из двух фильтров на уровне FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6: PERMIT для адресов loopback в пределах настроенного диапазона портов прокси (по умолчанию 60080–60089) и BLOCK для любого соединения, чей токен несёт SID srt-sandbox. Процесс в песочнице выходит в интернет только через JS HTTP/SOCKS5-прокси, слушающие в этом диапазоне; процесс, который удаляет переменные окружения прокси и подключается напрямую, блокируется на уровне ядра.

Изоляция файловой системы обеспечивается дискреционными ACL NTFS. Учётная запись srt-sandbox не имеет собственных прав на файлы вызывающего пользователя, поэтому при initialize() песочница добавляет аддитивные наследуемые явные ACE только для SID srt-sandbox — она никогда не переписывает и не заменяет существующий дескриптор безопасности пути:

filesystem.allowWrite → наследуемый ACE ALLOW MODIFY (READ|WRITE|EXECUTE|DELETE, без FILE_DELETE_CHILD). Процесс в песочнице может создавать, изменять и удалять файлы внутри рабочего дерева; изъятие FILE_DELETE_CHILD из предоставленных прав — это эшелонированная защита для приведённых ниже запрещающих ACE, а не защита корня дерева.
filesystem.allowRead → наследуемый ACE ALLOW READ|EXECUTE
filesystem.denyRead / filesystem.denyWrite → наследуемый ACE DENY на целевой объект, плюс наследуемый DENY FILE_DELETE_CHILD на его родителя — вместе с изъятым FILE_DELETE_CHILD в предоставлении на рабочее дерево это не даёт процессу в песочнице переименовать или удалить запрещённый путь через его родительский каталог

reset() удаляет все ACE, добавленные этим сеансом (с подсчётом ссылок для параллельных хостов через state.db; проход восстановления после сбоя при следующем initialize() убирает последствия некорректного завершения). Поддерживаются целевые каталоги (ACE наследуются на всё поддерево). Glob-шаблоны разворачиваются в конкретные пути на этапе initialize() — путь, соответствующий шаблону, но появившийся позже, не покрывается.

TLS-терминирование в Windows

network.tlsTerminate требует наличия MITM-ЦС в хранилище сертификатов CurrentUser\Root пользователя песочницы (schannel — TLS-бэкенд, используемый System32\curl.exe, PowerShell Invoke-WebRequest, .NET и git с бэкендом по умолчанию, — доверяет только системному хранилищу, а не переменным окружения). Это шаг установки, отдельный от windows-install:```typescript import { windowsTrustCa } from '@anthropic-ai/sandbox-runtime' windowsTrustCa('/path/to/mitm-ca.crt') // or: srt-win user trust-ca

`initialize()` сравнивает отпечаток CA текущего сеанса с установленным и при несовпадении завершается с сообщением, подсказывающим, как исправить ситуацию, поэтому устаревший установочный CA не может незаметно нарушить TLS внутри песочницы.

Клиенты на базе OpenSSL (msys2 `curl`, `git -c http.sslBackend=openssl`, Node, Python, cargo) охвачены уровнем доверия через переменные окружения: тот же набор доверенных сертификатов, что используется на macOS/Linux, передаётся в песочницу через `NODE_EXTRA_CA_CERTS`, `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, `GIT_SSL_CAINFO`, `CARGO_HTTP_CAINFO` и т.д., а путь к набору добавляется в разрешение `allowRead` сеанса, чтобы учётная запись песочницы могла открыть его.

### Конфигурация для Windows

Кроссплатформенные блоки `filesystem` и `network` применяются, как описано выше. Параметры только для Windows находятся в `windows`:

- `windows.proxyPortRange` — включающий диапазон портов `[low, high]`, к которому привязываются JS-прокси. **Должен совпадать** с диапазоном, переданным в `windows-install --proxy-port-range` (по умолчанию `[60080, 60089]`) — WFP-правило PERMIT для loopback покрывает только этот диапазон.
- `windows.sublayerGuid` — GUID подслоя WFP, в который были установлены фильтры. Опустите, чтобы использовать значение по умолчанию на момент компиляции; задавайте только когда корпоративные инструменты установили фильтры в пользовательский подслой.
- `windows.srtWin.path` — путь к исполняемому файлу `srt-win`. Опустите, чтобы использовать упакованный `vendor/srt-win/<arch>/srt-win.exe`. Задавайте, если CLI `srt-win` встроен в многокомандный бинарный файл; тогда при запуске `--srt-win` передаётся как `argv[1]`, чтобы диспетчер встраивающего приложения мог направить вызов в `srt_win::run_from_args`.

### Известные ограничения

- **Проверка отзыва сертификатов в schannel.** Запрос CRL/OCSP через CryptoAPI выполняется через WinHTTP под токеном вызывающего процесса, игнорируя прокси-окружение, поэтому блокируется WFP-ограждением исходящего трафика. Инструменты, использующие schannel с включённой по умолчанию проверкой отзыва, завершаются с ошибкой `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`), если отзыв не отключить для конкретного инструмента: `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`. `Invoke-WebRequest`, .NET `HttpClient` и `gh` не проверяют отзыв по умолчанию и не затрагиваются. Планируется точка распространения CRL, обслуживаемая через loopback-прокси, чтобы убрать этот обходной путь.
- **Установленные для пользователя инструменты недоступны.** Процесс в песочнице работает как `srt-sandbox`, а не под вашей учётной записью, поэтому инструменты, установленные в вашем профиле (Node под управлением nvm/fnm, пакеты `winget`/Scoop для текущего пользователя, `pip install --user`, `%LOCALAPPDATA%\Programs\…`), находятся через унаследованный `PATH`, но не могут быть открыты учётной записью песочницы. Предпочитайте установку для всей машины (`Program Files`, `choco`/`winget --scope machine`) или добавляйте конкретные пути профиля в `filesystem.allowRead`.
- **Переопределения `filesystem.allowRead` / `filesystem.allowWrite` для каждого запуска не поддерживаются.** `allowRead`/`allowWrite` уровня сеанса (в конфиге, переданном в `initialize()`) работают, как описано выше; передача их для отдельной команды в `customConfig` у `wrapWithSandbox` вызывает исключение — разрешения применяются на весь сеанс через `srt-win acl grant` в `initialize()`, а `srt-win exec` предоставляет только запреты для конкретного запуска.
- **`proxyAuthToken` виден в командной строке запускающего процесса.** Прокси-окружение (включая `HTTP_PROXY=http://srt:<token>@127.0.0.1:…`) передаётся двухшаговому запускающему процессу как аргументы `--env` в argv `srt-win exec`, поэтому токен доступен любому локальному субъекту, который может открыть процесс запускающего приложения с правами `PROCESS_QUERY_LIMITED_INFORMATION`. Токен существует, чтобы процесс в песочнице мог аутентифицироваться на loopback-прокси, так что он не является секретом от самой песочницы; на однопользовательской машине для разработки это обычно приемлемо, но на общем хосте считайте список разрешённых через прокси адресов доступным другим субъектам той же сессии.
- **Разрешение DNS через системный резолвер не ограничено.** `getaddrinfo()` обслуживается службой `Dnscache`, работающей как `NETWORK SERVICE`, поэтому разрешение имён выполняется успешно, даже если последующий `connect()` из процесса в песочнице блокируется. Инструменты, которые сами работают по UDP/53 (`nslookup`, `dig`), попадают под ограничение. Это повторяет поведение macOS.

### Удаление```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

Удаляет набор фильтров WFP, учётную запись srt-sandbox и её профиль, группу sandbox-runtime-users и очищает маркер учётных данных/настройки из state.db (один запрос UAC). Сам %LOCALAPPDATA%\sandbox-runtime\state.db остаётся на месте (он имеет ACL только для брокера); для полной очистки удалите каталог вручную.

Разработка```bash

Install dependencies

npm install

Build the project

npm run build

Run tests

npm test

Type checking

npm run typecheck

Lint code

npm run lint

Format code

npm run format

### Сборка Seccomp-бинарников

BPF-фильтр и загрузчик `apply-seccomp` компилируются из C-исходников в `vendor/seccomp-src/` через `npm run build:seccomp` (только Linux; требуются `gcc` и `libseccomp-dev`). CI запускает сборку перед тестами для каждой архитектуры Linux, а release-workflow собирает обе архитектуры и включает их в публикуемый пакет.

## Детали реализации

### Архитектура сетевой изоляции

Песочница запускает HTTP- и SOCKS5-прокси-серверы на хост-машине, которые фильтруют все сетевые запросы на основе правил разрешений:

1. **HTTP/HTTPS-трафик**: HTTP-прокси-сервер перехватывает запросы и проверяет их на соответствие разрешённым/запрещённым доменам
2. **Прочий сетевой трафик**: SOCKS5-прокси обрабатывает все остальные TCP-соединения (SSH, подключения к базам данных и т.д.)
3. **Принудительное применение разрешений**: Прокси обеспечивают соблюдение правил `permissions` из вашей конфигурации

**Обмен данными с прокси в зависимости от платформы:**

- **Linux**: Запросы направляются через файловую систему по Unix-сокетам (с использованием `socat` для моста). Сетевое пространство имён удаляется из контейнера bubblewrap, что гарантирует прохождение всего сетевого трафика через прокси.

- **macOS**: Профиль Seatbelt разрешает связь только с конкретными портами localhost, на которых слушают прокси. Весь остальной сетевой доступ блокируется.

- **Windows**: WFP-фильтр `ALE_AUTH_CONNECT` блокирует все исходящие подключения от учётной записи `srt-sandbox`, кроме loopback-подключений к настроенному диапазону портов прокси. Прокси привязываются внутри этого диапазона. Переменные окружения (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, …) направляют инструменты на прокси, но именно WFP-фильтр является границей — процесс, который игнорирует или сбрасывает их, всё равно остаётся изолированным.

### Изоляция файловой системы

Ограничения файловой системы применяются на уровне ОС:

- **macOS**: Используется `sandbox-exec` с динамически генерируемыми профилями Seatbelt, которые определяют разрешённые пути чтения и записи
- **Linux**: Используется `bubblewrap` с bind-mount'ами, помечающими каталоги как доступные только для чтения или для чтения и записи в зависимости от конфигурации
- **Windows**: Записываются аддитивные явные ACE `(OI)(CI)` для SID `srt-sandbox` на настроенные пути (ALLOW для `allowRead`/`allowWrite`, DENY для `denyRead`/`denyWrite`), затем они удаляются при вызове `reset()`

**Разрешения файловой системы по умолчанию:**

- **Чтение** (запрет-затем-разрешение): Разрешено везде по умолчанию. Можно запрещать крупные области, а затем повторно разрешать конкретные пути внутри них. `allowRead` имеет приоритет над `denyRead`.

  - Пример: `denyRead: ["~/.ssh"]` для блокировки доступа к SSH-ключам
  - Пример: `denyRead: ["/Users"], allowRead: ["."]` для блокировки всего `/Users`, кроме рабочей папки
  - Пустой `denyRead: []` = полный доступ на чтение (ничего не запрещено)

- **Запись** (только разрешение): Запрещена везде по умолчанию. Необходимо явно разрешить пути.
  - Пример: `allowWrite: [".", "/tmp"]` для разрешения записи в текущий каталог и /tmp
  - Пустой `allowWrite: []` = нет доступа на запись (ничего не разрешено)
  - `denyWrite` создаёт исключения внутри разрешённых путей (запрет имеет приоритет)

**Приоритет намеренно противоположен для чтения и записи:** `allowRead` переопределяет `denyRead`, тогда как `denyWrite` переопределяет `allowWrite`. Это позволяет выделять читаемые области внутри запрещённых зон и защищённые области внутри доступных для записи зон.

### Обязательные запрещённые пути (автоматически защищаемые файлы)

Определённые чувствительные файлы и каталоги **всегда заблокированы для записи**, даже если они попадают в разрешённый путь записи. Это обеспечивает многоуровневую защиту от побега из песочницы и подмены конфигурации.

**Всегда блокируемые файлы:**

- Файлы конфигурации оболочки: `.bashrc`, `.bash_profile`, `.zshrc`, `.zprofile`, `.profile`
- Файлы конфигурации Git: `.gitconfig`, `.gitmodules`
- Прочие чувствительные файлы: `.ripgreprc`, `.mcp.json`

**Всегда блокируемые каталоги:**

- Каталоги IDE: `.vscode/`, `.idea/`
- Каталоги конфигурации Claude: `.claude/commands/`, `.claude/agents/`
- Хуки и конфигурация Git: `.git/hooks/`, `.git/config`

Эти пути блокируются автоматически — вам не нужно добавлять их в `denyWrite`. Например, даже с `allowWrite: ["."]` запись в `.bashrc` или `.git/hooks/pre-commit` завершится ошибкой:```bash
$ 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:```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- По умолчанию: `3` (поиск на глубину до 3 уровней)
- Диапазон: от `1` до `10`
- Более высокие значения обеспечивают большую защиту, но снижают производительность
- Файлы в CWD (глубина 0) защищены всегда, независимо от этой настройки

### Ограничения Unix-сокетов (Linux)

В Linux песочница использует **seccomp BPF (Berkeley Packet Filter)** для блокировки создания сокетов домена Unix на уровне системных вызовов. Это обеспечивает дополнительный уровень безопасности, предотвращающий создание процессами новых сокетов домена Unix для локального IPC (если это явно не разрешено).

**Как это работает:**

1. **Встроенный BPF-фильтр**: Пакет поставляется со статическим бинарником `apply-seccomp` для x64 и arm64, в который скомпилирован seccomp BPF-фильтр. Фильтр зависит от архитектуры, но не зависит от libc, поэтому бинарник работает и с glibc, и с musl.

2. **Определение во время выполнения**: Песочница автоматически определяет архитектуру вашей системы и использует соответствующий бинарник `apply-seccomp`.

3. **Фильтрация системных вызовов**: BPF-фильтр перехватывает системный вызов `socket()` и блокирует создание сокетов `AF_UNIX`, возвращая `EPERM`. Это предотвращает создание новых сокетов домена Unix кодом внутри песочницы.

4. **Двухэтапное применение с помощью бинарника apply-seccomp**:
   - Внешний bwrap создаёт песочницу с ограничениями файловой системы, сети и пространства имён PID
   - Процессы сетевого моста (socat) запускаются внутри песочницы (им нужны Unix-сокеты)
   - apply-seccomp создаёт вложенное пространство имён user+PID+mount и заново монтирует `/proc`
   - Внутри вложенного пространства имён apply-seccomp выступает в роли PID 1 (non-dumpable init/reaper)
   - apply-seccomp выполняет fork, применяет seccomp-фильтр через `prctl()` и запускает команду пользователя через exec
   - Команда пользователя выполняется со всеми ограничениями песочницы плюс блокировкой создания Unix-сокетов

**Изоляция пространства имён PID**: Вложенное пространство имён PID гарантирует, что команда пользователя не может видеть или адресовать ни один процесс, работающий без seccomp-фильтра (init от bwrap, обёртка shell или вспомогательные процессы socat). Это сохраняет целостность seccomp-границы независимо от `kernel.yama.ptrace_scope`, поскольку вспомогательные процессы без фильтра недоступны через `ptrace` или `/proc/N/mem`. Внутренний PID 1 устанавливает `PR_SET_DUMPABLE=0`, поэтому он также недоступен для ptrace. Если создание вложенного пространства имён не удаётся, apply-seccomp прерывает работу, а не запускается без изоляции.

**Ограничения безопасности**: Фильтр блокирует `socket(AF_UNIX, ...)` и системные вызовы `io_uring_setup`/`io_uring_enter`/`io_uring_register` (последние три — потому что `IORING_OP_SOCKET` в Linux 5.19+ иначе обошёл бы правило `socket()`). Он не предотвращает операции с файловыми дескрипторами Unix-сокетов, унаследованными от родительских процессов или переданными через `SCM_RIGHTS`. Для большинства сценариев использования песочницы блокировки создания сокетов достаточно для предотвращения несанкционированного IPC.

**Ноль зависимостей во время выполнения**: Предварительно собранные статические бинарники apply-seccomp и предварительно сгенерированные BPF-фильтры включены для архитектур x64 и arm64. Никаких инструментов компиляции или внешних зависимостей во время выполнения не требуется.

**Поддержка архитектур**: x64 и arm64 полностью поддерживаются с помощью предварительно собранных бинарников. Другие архитектуры в настоящее время не поддерживаются. Чтобы использовать песочницу без блокировки Unix-сокетов на неподдерживаемых архитектурах, установите `allowAllUnixSockets: true` в вашей конфигурации.

### Обнаружение нарушений и мониторинг

Когда процесс в песочнице пытается получить доступ к ограниченному ресурсу:

1. **Блокирует операцию** на уровне ОС (возвращает ошибку `EPERM`)
2. **Регистрирует нарушение** (механизмы зависят от платформы)
3. **Уведомляет пользователя** (в Claude Code это вызывает запрос разрешения)

**macOS**: Среда выполнения песочницы использует хранилище журналов нарушений системной песочницы macOS. Это обеспечивает уведомления в реальном времени с подробной информацией о том, что было предпринято и почему это было заблокировано. Это тот же механизм, который Claude Code использует для обнаружения нарушений.```bash
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog

Linux: Bubblewrap не предоставляет встроенной отчётности о нарушениях. Используйте strace для трассировки системных вызовов и выявления заблокированных операций:```bash

Trace all denied operations

strace -f srt 2>&1 | grep EPERM

Trace specific file operations

strace -f -e trace=open,openat,stat,access srt 2>&1 | grep EPERM

Trace network operations

strace -f -e trace=network srt 2>&1 | grep EPERM

### Продвинутый уровень: используйте собственный прокси

Для более сложной фильтрации сетевого трафика вы можете настроить песочницу на использование собственного прокси-сервера вместо встроенных. Это позволяет:

- **Проверка трафика**: используйте такие инструменты, как [mitmproxy](https://mitmproxy.org/), для проверки и изменения трафика
- **Пользовательская логика фильтрации**: реализуйте сложные правила, выходящие за рамки простых списков разрешённых доменов
- **Журналирование аудита**: записывайте все сетевые запросы для соответствия требованиям или отладки

**Пример с mitmproxy:**```bash
# 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.

Users should be aware of potential risks that come from allowing broad domains like `github.com` that may allow for data exfiltration. Also, in some cases it may be possible to bypass the network filtering through [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).

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.
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 enableWeakerNestedSandbox mode that enables it to work inside of Docker environments without privileged namespaces. This option considerably weakens security and should only be used in cases where additional isolation is otherwise enforced.
Weaker Network Isolation (macOS): The enableWeakerNetworkIsolation option re-enables access to com.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 using httpProxyPort with a MITM proxy and custom CA).
Apple Events (macOS): The allowAppleEvents option re-enables sending Apple Events and Launch Services open requests ((allow appleevent-send), (allow lsopen), and mach-lookups for com.apple.coreservices.appleevents, com.apple.CoreServices.coreservicesd, and com.apple.coreservices.quarantine-resolver), which open, osascript, and URL-opening helpers require. With these allowed, a sandboxed command can launch arbitrary applications with no user prompt, and launched applications run outside the sandbox entirely — so this option removes code-execution isolation, not just weakens it. Scripting already-running applications via Apple Events is additionally gated by macOS TCC automation consent, but launching via open is not. Only enable this when commands inside the sandbox genuinely need to open URLs or applications.

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 proxychains with LD_PRELOAD on 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 run strace to see violations, unlike macOS which has automatic violation monitoring via the system log store

sandbox-runtime v0.0.71

Категории