clawk: одноразовая VM для AI-агентов вместо вашей

Дайте агенту собственную одноразовую Linux-машину, а не вашу.

Агент по написанию кода по-настоящему полезен только тогда, когда ему позволяют что-то делать: устанавливать пакеты, запускать написанный код, поднимать серверы, работать с сетью. На вашей собственной машине это оставляет лишь два неудобных варианта. Либо подтверждать каждую команду (и неотрывно следить за приглашением каждые несколько секунд), либо запускать --dangerously-skip-permissions и надеяться, что ни один rm -rf и ни один утёкший токен ничего важного не уничтожит.

clawk — это третий вариант. Перейдите в репозиторий, введите clawk, и Claude Code (или Codex, или pi, или обычный шелл) начнёт работу внутри одноразовой виртуальной Linux-машины: ваш код смонтирован внутри, гость работает под root, никаких запросов на подтверждение — а ваши файлы, связка ключей и всё остальное на хосте остаются недосягаемы. Агент получает собственную машину вместо вашей.

Демонстрация clawk: запуск VM и подключение claude, заблокированная попытка отправить данные на неизвестный сервер, восстановление сессии командой clawk attach

Одна команда — и агент готов к работе; попытка отправить данные на неизвестный сервер заблокирована сетевым allow-list; clawk attach возобновляет сессию позже.

Граница здесь — не правило в промпте, которое агента можно уговорить обойти. Это отдельная машина, и единственные точки входа в неё — те, что вы явно смонтировали. Из шелла внутри песочницы:

$ curl https://tracker.evil.example   # not on the allow-list: blocked
curl: (7) Failed to connect to tracker.evil.example port 443 after 2 ms: Connection refused

$ cat ~/.ssh/id_rsa                   # your keys never entered the VM
cat: /home/agent/.ssh/id_rsa: No such file or directory

$ git push                            # ...yet this works: ssh-agent is forwarded
Enumerating objects: 5, done.

Честно об ограничениях: allow-list блокирует соединения с неизвестными серверами, а не с теми, что вы разрешили. github.com разрешён заранее, и проброшенный ssh-agent может делать push, — так что считайте: всё, что агент может прочитать, он потенциально может и опубликовать. Подробнее об этом — в разделе «Модель безопасности и её ограничения».

Если агент сломает VM, достаточно запустить clawk destroy && clawk: свежая VM, тот же репозиторий, а --resume восстановит разговор.

Важно

Версия до 1.0, активно развивается. Ожидайте ломающих изменений между релизами и отдельных шероховатостей — что-то может и будет ломаться. Пожалуйста, создавайте issues: эта обратная связь формирует версию 1.0.

Основные возможности

Агент может делать всё что угодно. Он работает в одноразовой VM с ограниченной сетью, поэтому rm -rf, установка пакетов и запуск недоверенного кода не могут затронуть хост, ваши файлы или что-либо, чем вы явно не поделились.
Готов к работе одной командой. Перейдите в репозиторий и запустите clawk. Никаких Dockerfile, devcontainer или файлов настройки. Первый запуск собирает rootfs из вашего образа; каждый последующий занимает секунды.
Ломайте VM, не теряя ничего важного. Уничтожайте и пересоздавайте её свободно: код и разговоры с агентом живут на хосте. Теряется только диск одноразовой VM.
Настоящий Linux-бокс с вашим инструментарием. Любой OCI-образ становится rootfs: полноценная ОС именно с теми инструментами, которые нужны проекту. Docker-демон не требуется.
Секреты остаются на вашей машине. Исходящий трафик ограничен allow-list, а ssh-agent пробрасывается, так что git push работает без передачи ключей в VM.
Отдельная песочница на проект или задачу. Можно запускать несколько одновременно; для задач, охватывающих несколько репозиториев, создаётся git worktree на каждый репозиторий с координированными PR. Простаивающие VM автоматически освобождают память и уходят в спячку, так что забытая песочница обходится (почти) бесплатно.

Зачем VM?

clawk — это среда общего назначения для локальной работы автономных агентов по написанию кода. VM здесь и есть суть: это целая машина, которой агент может полностью владеть, а не процесс, обёрнутый в политики поверх вашей.

Отдельное ядро. Гостевая система запускает собственное ядро Linux, поэтому файловая система хоста не скрыта за правилами запрета — она попросту никогда не монтировалась.
Обычная Linux-среда. Стандартное ядро, стандартный userland, привычная среда с /dev/kvm — инструменты ведут себя так, как написано в их документации, без неожиданностей от фильтров системных вызовов.
Root внутри гостя. Устанавливайте системные пакеты, редактируйте /etc, загружайте модули, занимайте привилегированные порты. Агент может перенастраивать этот бокс как угодно.
Одноразовый жизненный цикл. Сломать дёшево, пересоздать быстро; сломанная VM — это один clawk destroy && clawk, а репозиторий и разговоры на хосте не тронуты.
Более строгая изоляция от хоста. Изоляция держится на границе гипервизора, а не на том, правильно ли выстроена политика изоляции процессов.

Такая комбинация даёт возможность выполнять задачи, с которыми ограниченная процессная песочница постоянно конфликтует:

установка пакетов и нативных зависимостей;
запуск фоновых сервисов (базы данных, очереди, dev-серверы);
выполнение недоверенных сборок и тестов на полной скорости;
использование системного Linux-инструментария, рассчитанного на настоящую машину;
и, при наличии KVM-поддержки в гостевом ядре на совместимом железе, работа с контейнерами и Kubernetes — Docker или Kind могут работать внутри песочницы. Это опциональная возможность, требующая поддержки железа; точные требования — в документации Images.

Всё это — не самоцель; clawk предназначен для локальной работы с агентами в целом. Docker и Kubernetes — просто самый наглядный пример «нужна настоящая машина, а не изолированный процесс».

Установка

Требует macOS 14+ на Apple Silicon. (Linux поддерживается через Firecracker и пока является экспериментальным — начните с docs/linux-quickstart.md, где описаны настройка, рабочий процесс и известные ограничения. Этот README ориентирован на macOS.)

brew install clawkwork/tap/clawk

Из исходников (для контрибьюторов или тех, кто не использует Homebrew) нужен Go 1.26+:

git clone https://github.com/clawkwork/clawk && cd clawk
make install

В обоих случаях никаких дополнительных инструментов на хосте не требуется: ни Docker, ни qemu, ни sudo. Гипервизор — Apple Virtualization.framework, встроенный прямо в бинарный файл, а релизные сборки включают предварительно собранный агент внутри гостя — так что Go-инструментарий нужен только при сборке из исходников, но тогда он у вас и так есть. При первом запуске clawk проверит, всего ли хватает, и предложит устранить недостающее.

Удаление: выполните clawk destroy для своих песочниц, затем rm -rf ~/.clawk, после чего удалите бинарный файл командой brew uninstall clawk (или удалите его из $GOBIN при установке из исходников). Больше ничего установлено не было: никаких launchd-задач; демоны на каждую песочницу — обычные процессы, которые завершаются вместе со своими VM.

Быстрый старт

Самый частый сценарий — песочница для текущей директории:

cd ~/code/my-project
clawk                      # boot a sandbox for this dir + attach claude
clawk run shell            # drop into a shell in the same sandbox
clawk run codex            # or another agent: codex, pi, opencode, shell
clawk down                 # stop the VM (repo + agent state persist)
clawk attach               # come back later — boots if stopped, reattaches claude
clawk destroy              # remove the VM (conversation history is kept)

Часто используемые опции:

clawk run claude -- --resume            # pass args through to the agent
clawk forward add my-project 3000       # expose a guest dev server on localhost:3000
clawk network allow my-project api.example.com

Работаете над задачей, затрагивающей несколько репозиториев? Одна команда создаёт песочницу с git worktree на каждый репозиторий в свежей ветке, а clawk pr позже открывает взаимосвязанные PR для всего, что изменилось:

cd ~/code/my-workspace     # contains a clawk.mod listing the repos
clawk work INFRA-123       # one sandbox, a worktree per repo, claude attached
clawk pr INFRA-123         # push branches + open one PR per repo

Полный жизненный цикл задачи (статус, дополнительные ветки после мержей, rebase) описан в docs/ticket-mode.md.

Совет

Используете Claude Code? Один раз выполните claude setup-token, затем clawk auth set-token — и каждая новая песочница будет сразу авторизована, без /login и без конфликтов входа между параллельными песочницами. Подробнее: docs/claude-auth.md.

Что переживает какие операции

Всё определяет одно правило: VM одноразова; всё, что жалко потерять, живёт на хосте.

clawk down clawk destroy

	`clawk down`	`clawk destroy`
Ваш репозиторий (смонтированный worktree; коммиты, ветки)	✅	✅
Состояние агента (разговоры Claude/Codex/pi/opencode, память)	✅	✅
Диск VM (apt-пакеты, кэши, `$HOME`)	❌ (пересобирается при каждом запуске*)	❌ (в этом и смысл)

Ваш репозиторий (смонтированный worktree; коммиты, ветки)

✅

Состояние агента (разговоры Claude/Codex/pi/opencode, память)

✅

Диск VM (apt-пакеты, кэши, $HOME)

❌ (пересобирается при каждом запуске*)

❌ (в этом и смысл)

\* Два исключения: при восстановлении из clawk snapshot диск и память восстанавливаются точно в том состоянии, в котором были сохранены; Linux/Firecracker-провайдер сохраняет диск до выполнения destroy. Всё, что нужно при каждом запуске, должно быть в образе (vm ( image … )); разовая настройка при запуске — в хуках on up.

Состояние агента монтируется с хоста для каждой песочницы: домашняя директория каждого раннера — ~/.claude/ у claude, ~/.codex/ у codex, ~/.pi/ у pi, две XDG-директории у opencode — живут на хосте по пути ~/.clawk/namespaces/default/state/<name>/, и пересозданная песочница подхватит старые разговоры с помощью --resume. Именно этот монтаж делает обещание реальным: диск VM заново клонируется из образа при каждом запуске, поэтому всё, что раннер записал за пределами этих директорий, исчезает после следующего clawk up.

Полная автономия по умолчанию (и флаг `--safe` для отключения)

Раннеры запускаются в режиме «внешней песочницы»: claude получает --dangerously-skip-permissions, codex — --dangerously-bypass-approvals-and-sandbox, pi — --approve (у него нет запросов на подтверждение, которые можно было бы обойти — встроенной песочницы нет вообще — но он всё же требует подтверждения для локальных настроек .pi/ и расширений), opencode получает --auto. На вашей собственной машине эти флаги были бы безрассудством; здесь они и есть суть: граница VM и сетевой allow-list обеспечивают изоляцию, так что агент работает на полной скорости без запросов на каждое действие. Агент может влиять только на то, что вы смонтировали и разрешили в allow-list — и ни на что сверх этого (см. SECURITY.md).

Предпочитаете всё-таки видеть запросы на подтверждение? Добавьте --safe к любой команде attach (clawk --safe, clawk run claude --safe), и раннер запустится без флагов обхода для данной сессии.

Сеть

Исходящий трафик по умолчанию запрещён; у каждой песочницы свой allow-list. DNS разрешает всё; TCP, UDP (включая QUIC) и ICMP echo к узлам, не включённым в список, отклоняются. Популярные реестры (npm, PyPI, crates.io, GitHub, Anthropic и другие) разрешены заранее, а фильтр учитывает DNS — так что разрешение example.com продолжает работать при ротации IP-адресов.

clawk network allow my-project api.stripe.com '*.internal.mycorp.com' 10.0.0.5
clawk network denials my-project     # what the agent tried that got blocked
clawk forward add my-project 3000    # localhost:3000 → the guest's dev server
clawk forward add-reverse my-project 63342   # and the other way: a service on YOUR
                                             # localhost, reachable inside the guest

Блокировки записываются по имени хоста, которое разрезолвил гость, так что clawk network denials читается как лог всего, к чему агент пытался обратиться. Переиспользуемые именованные политики (включая подписку на внешние blocklist-ы вроде oisd) и цепочка use для их комбинирования описаны в docs/networking.md.

Конфигурация: `clawk.mod`

Файл конфигурации не обязателен — настройки по умолчанию разумны. Когда проекту нужно больше, всё описывается в файле clawk.mod с синтаксисом в стиле go.mod:

sandbox my-project (
    vm (
        cpu    4
        memory 8GiB
        image  golang:1.25          # any OCI image is the rootfs
    )
    network ( allow api.example.com )
    forwards ( 3000 )
    env ( DATABASE_URL )            # forward a host var; values come from your shell
    # also: GH=${OTHER_NAME}, LOG=${LOG:-info} defaults, API=${API:?required}
    mcp (                           # MCP servers, ready on first boot
        linear https://mcp.linear.app/mcp header "Authorization: Bearer ${LINEAR_TOKEN}"
    )
    on create ( "go mod download" )
    agent (
        instructions "Ask before running destructive commands."
    )
)

Блок является шаблоном: он фиксируется в момент создания песочницы, так что работающая песочница никогда неожиданно не меняется. Полный справочник (shares, секретные файлы, skills, предзаполнение памяти агента, корни многорепозиторных рабочих пространств) — в docs/configuration.md; MCP-серверы и способ хранения их учётных данных вне диска — в docs/mcp.md; подключение USB-serial платы с вашего Mac внутрь песочницы для работы с микроконтроллерами — в docs/serial.md; образы и пользовательские гостевые ядра (включая ядро с KVM для вложенной виртуализации) — в docs/images.md.

Жизненный цикл

clawk list                  # all sandboxes
clawk status [<name>]       # state, forwards, blocked hosts; --json for scripts
clawk up / down             # boot / stop
clawk pause / resume        # suspend / resume the running VM in memory
clawk snapshot              # save to disk: RAM freed, guest intact; resume restores it
clawk destroy               # remove the VM; host-side state persists

clawk snapshot — это гибернация для песочниц: память гостя сохраняется рядом с его диском, а следующий запуск восстанавливает гостя ровно в том месте, где он остановился. Фоновые процессы и dev-серверы продолжат работу как ни в чём не бывало, а clawk attach вернёт вас к агенту. Полная поверхность команд, диспетчеризация раннеров и механизм управления простаивающими VM (balloon-память, admission control, автоостановка) описаны в docs/commands.md.

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

you ──▶ clawk CLI ──▶ per-sandbox daemon (detached; owns the VM)
                        ├─ gvproxy: in-process userspace TCP/IP stack —
                        │  the DNS-aware outbound filter the guest can't reconfigure
                        ├─ vsock bridge to the in-guest pty-agent (no sshd)
                        ├─ ssh-agent proxy, macOS (signing stays on the host)
                        └─ VM: Virtualization.framework (macOS) / firecracker (Linux)
                             ├─ clawk-init, PID 1 (no systemd, no cloud-init)
                             ├─ your repo, live-mounted over virtio-fs
                             └─ claude / codex / pi / shell on a PTY

Несколько осознанных решений, кратко:

rootfs — обычный OCI-образ. clawk скачивает его (без Docker-демона), разворачивает слои и напрямую записывает ext4-диск — без root и без loop-устройств. Каждая песочница из одного образа — это copy-on-write клон (APFS clonefile / FICLONE), так что дисковое пространство на каждую песочницу — это только то, что гость записал сам.
Сеть фильтруется ниже уровня гостя. Весь L3 VM (шлюз, DHCP, DNS, NAT) — это userspace-стек внутри процесса демона. Каждое исходящее соединение и каждый DNS-ответ проверяются по allow-list там, где даже root внутри гостя не может этого изменить. Никаких iptables на хосте, никакого sudo.
Один путь внутрь. Никакого sshd, никакого cloud-init: единственный путь управления в гостевую систему — один vsock-агент, и каждое подключение — в стиле container exec: свежий процесс, который завершается при разрыве соединения.

Полная картина (гостевой стек, оба провайдера, сетевая архитектура на уровне фреймов) — в ARCHITECTURE.md, а обоснование каждого решения — в DESIGN.md.

Сравнение с альтернативами

Контейнеры и devcontainers. Они используют общее ядро и видят вашу файловую систему минус правила запрета; единственная ошибка в ядре или случайное монтирование могут раскрыть хост. Devcontainer-конфигурации нередко монтируют Docker-сокет хоста для сборки образов, передавая контейнеру управление демоном хоста; clawk, напротив, держит Docker внутри VM. И никакого Dockerfile/devcontainer.json писать не нужно: любой OCI-образ становится rootfs.
Системные песочницы для агентов. Инструменты вроде Anthropic sandbox-runtime применяют политики на уровне процессов на вашей реальной машине: отлично для лёгких правил, но одна ошибка в политике обнажает всё (включая связку ключей), а установка пакетов, фоновые сервисы или вложенный гипервизор в такой среде безопасно разрешить непросто. clawk переносит всю рабочую нагрузку на отдельную машину.
Менеджеры VM общего назначения (например, Lima). Lima даёт вам Linux VM; clawk — это рабочий процесс поверх неё: VM на каждый проект со смонтированным репозиторием, подключённым и авторизованным агентом, egress по умолчанию через allow-list с логированием блокировок, разговоры с агентом, сохраняющиеся через destroy, и режим задач для управления worktree и PR. (Под капотом оба используют Virtualization.framework.)
Облачные песочницы. clawk работает локально: ваш код никуда не уходит, ничего не тарифицируется по часам, а worktree, который редактирует агент, — тот же самый, что открыт в вашем редакторе, смонтированный в реальном времени на macOS (Linux-провайдер пока запекает его при создании; см. Roadmap). Облачные песочницы подходят для флотов; clawk — для машины на вашем столе.

Модель безопасности и её ограничения

Две границы выполняют всю работу: VM (файловая система хоста невидима, кроме того, что вы смонтировали) и исходящий allow-list (применяется в userspace ниже уровня гостя, для каждого протокола). От чего clawk не защищает:

Всё смонтированное и разрешённое — открыто. Worktree доступны на запись, поэтому агент может закоммитить плохой код или сделать push в любой репозиторий, доступный проброшенному ssh-agent. Проверяйте всё, что выходит из песочницы, как проверяли бы PR от незнакомца.
Секреты, которые вы передали внутрь, видны агенту. Содержимое files ( … ) и shares ( … ), проброшенные переменные окружения и токен Claude агент может прочитать (и, если адресат внесён в allow-list, отправить туда). Делитесь минимумом.
Побеги из гипервизора. clawk опирается на изоляцию Virtualization.framework/KVM и не добавляет защит сверх неё.

Если вы найдёте способ нарушить границу (побег из гостя на хост, обход сетевого фильтра, утечка учётных данных), пожалуйста, сообщите об этом в приватном порядке через SECURITY.md.

Часто задаваемые вопросы

Каковы накладные расходы? Первый запуск из образа требует единовременной сборки rootfs (скачивание → разворачивание слоёв → ext4). После этого диски — copy-on-write клоны, ядро загружается напрямую, без прошивки и установщика. Простаивающие VM освобождают память до ~1 ГиБ, автоматически останавливаются через 30 минут простоя и могут быть сохранены на диск — тогда расходуют только место на диске.

Работает ли на Intel Mac? На Windows? Нет. macOS требует Apple Silicon (macOS 14+). На Linux Firecracker-провайдер работает, но в экспериментальном режиме (см. docs/commands.md). Поддержки Windows нет.

Нужен ли установленный Docker? Нет. clawk самостоятельно скачивает OCI-образы и собирает загрузочные диски. Docker-образы — это формат входных данных; Docker Engine не задействован. (Запуск Docker-демона внутри песочницы — это отдельная, опциональная возможность; требования к железу и ядру — в Images.)

Почему «clawk»? Знак — коготь (claw); clawkwork — игра слов на «A Clockwork Orange» («Заводной апельсин»). VM, которую вы заводите, отпускаете на волю — и всегда можете сбросить.

Roadmap

Следующий шаг — поддержка большего числа одновременно работающих песочниц, чем позволяет RAM.

Автоостановка со снапшотом. Ручная гибернация уже реализована как clawk snapshot / clawk resume; следующий шаг — автоматическая остановка по простою тоже будет использовать её, чтобы dev-серверы переживали остановку и приостановленная песочница расходовала только место на диске.
Лимит на число работающих VM. Вместо отказа от создания новой VM при исчерпании RAM — сохранять на диск наименее недавно использованную песочницу и запускать новую.
Паритет с Firecracker. Живая передача изменений worktree и синхронизация файлов хоста на Linux.

Статус

Версия до 1.0, активно разрабатывается и быстро меняется: ожидайте ломающих изменений между релизами. CLI-интерфейс меняется меньше всего, внутренности — больше всего, но ничто не зафиксировано до выхода 1.0.

Участие в разработке

Issues и PR приветствуются. Смотрите CONTRIBUTING.md для сборки и тестирования, ARCHITECTURE.md — как устроен проект, и DESIGN.md — куда он движется.

Лицензия

Apache License 2.0. clawk включает два сторонних компонента под собственными лицензиями (gvisor-tap-vsock, Apache-2.0; ext4-писатель из hcsshim, MIT); см. NOTICE.