Запускайте coding agents в одноразовій VM

Чому одноразова VM краща за ваш ноутбук

Дайте coding agent одноразову VM — і найгірше, що він може зробити, це знищити машину, яку можна відновити за десять хвилин. Agent і далі отримує root, встановлює пакети та запускає test suite, не запитуючи дозволу на кожен крок. Відмінність полягає в тому, куди потрапляють наслідки. На ноутбуці agent має спільний доступ до домашнього каталогу, де зберігаються ваші SSH keys, профіль браузера, файли .env та всі інші репозиторії, які ви коли-небудь клонували. На одноразовому сервері він має shell, checkout і більше нічого цінного для викрадення.

У цьому полягає весь аргумент. Йдеться не про ймовірність, а про асиметрію наслідків. Обережний agent на обережно налаштованому ноутбуці майже завжди працює без проблем. Якщо одного разу щось піде не так, наслідком буде не невдалий commit. Доведеться відновлювати систему з backup — якщо він у вас є.

Визначте радіус ураження, перш ніж сперечатися про нього

Радіус ураження — це сукупність об’єктів, до яких процес має доступ. Для агента, який працює від імені вашого звичайного користувача на вашій звичайній машині, ця сукупність більша, ніж уявляє більшість людей.

Вона охоплює ~/.ssh/id_ed25519, який зазвичай не зашифрований, оскільки вам набридло вводити парольну фразу. Вона охоплює ~/.aws/credentials і ~/.config/gh/hosts.yml, які за задумом зберігаються у відкритому тексті. Вона охоплює кожен сусідній репозиторій у ~/code, зокрема ті, де в локальному env-файлі зберігаються production connection strings. Вона також охоплює історію shell, у якій залишилися токени, вставлені вами одного разу. До неї належить і мережа, до якої підключений ваш ноутбук. Часто це домашня або офісна мережа з неавтентифікованими сервісами.

Для цього не потрібен зловмисний агент. Достатньо однієї впевнено неправильної команди. rm -rf "$BUILD_DIR"/* із невстановленим BUILD_DIR розгортається в /* і обходить стандартну відмову GNU rm видаляти сам /, git clean -xfd у неправильному каталозі, docker system prune -af --volumes, яка видаляє локальну базу даних, або корисна chmod -R 777 у домашньому каталозі. Агент навчався на тому самому інтернеті, який навчив цих команд усіх інших.

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

Математика вартості нудна, і саме в цьому її суть

Невеликий VPS коштує кілька доларів на місяць. Відновлення ноутбука розробника займає день — і це оптимальний випадок, коли ви одразу помітили проблему та мали резервну копію.

Порахуйте за власними цифрами. Візьміть свою погодинну ставку й помножте її на кількість годин, потрібних для перевстановлення операційної системи, відновлення домашнього каталогу, ротації ключа SSH, ротації персонального токена доступу та повторного клонування двадцяти репозиторіїв. Порівняйте отриману суму з вартістю дванадцяти місяців використання найменшого сервера, який пропонує ваш провайдер. Точка беззбитковості настає менш ніж після одного інциденту за кілька років, і для перевищення цього порога інцидент не має бути катастрофічним. Навіть одна втрачена половина дня через пошкоджене локальне середовище вже окупає рік.

Друга частина розрахунку — snapshots. Snapshot перед ризикованим запуском перетворює серйозні наслідки на сценарій «відкотити зміни й спробувати інший prompt» замість «відновити все своє життя». На ноутбуці, за яким ви зараз працюєте, така можливість відсутня, оскільки неможливо створити snapshot машини, яку ви використовуєте як робоче місце.

Ландшафт станом на жовтень 2026 року

Є три чесні відповіді на запитання «де запускати агента». Вони мають однаковий компроміс між двома чинниками: міцністю ізоляції та обсягом налаштувань, який ви готові прийняти.

Локальна micro VM. Інструменти цієї категорії запускають повноцінну virtual machine на вашому обладнанні, монтують у неї репозиторій і надають агенту root усередині неї. clawk — поточний приклад. Його основна ідея повністю відповідає тезі цього допису: надайте coding agents одноразову Linux VM, а не доступ до вашого ноутбука. Станом на жовтень 2026 року цей інструмент орієнтований на macOS 14 і новіші версії на Apple silicon, має експериментальну підтримку Linux через Firecracker і встановлюється командою brew install clawkwork/tap/clawk. Виконайте clawk у репозиторії, щоб запустити sandbox і підключити агента, clawk down — щоб зупинити його, а clawk destroy — щоб видалити його. Межу ізоляції забезпечує hypervisor, тому вона є надійною. Обмеження полягає в тому, що VM працює на машині, яку ви носите із собою, споживає її пам’ять і зупиняється, коли ви закриваєте кришку.

Контейнер. Docker — це варіант, який більшість користувачів уже має встановленим, і він справді корисний.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm видаляє контейнер після завершення роботи, а --network none повністю вимикає для нього мережу. Це хороший типовий варіант для збірки або тестового запуску. Важливо розуміти, чого це не забезпечує: контейнер використовує kernel хоста, тому вразливість kernel може дати змогу вийти за межі контейнера. Межа ізоляції також зникає одразу після додавання --privileged або монтування /var/run/docker.sock, щоб агент міг «використовувати Docker». Монтування Docker socket у контейнер рівнозначне наданню цьому контейнеру root на хості.

Звичайний VPS, який можна перебудувати. Не потрібен новий інструмент, є справжня межа на рівні kernel і snapshots провайдера, а сервер продовжує працювати, коли ви вимикаєте ноутбук. Саме цей підхід описано в решті цього посібника. Він найкраще підходить для тривалих запусків агента, оскільки процес, який триває чотири години, не залежить від того, чи ви вже пішли додому.

Шаблон для VPS: створіть для агента окремого користувача

Почніть із захищеного сервера. У перші десять хвилин на новому VPS описано налаштування, які не залежать від агента: оновлення, вхід не від імені root, SSH лише за ключем і firewall.

Потім створіть обліковий запис, призначений лише для агента. Помилка в його середовищі не зможе вплинути на інші компоненти сервера.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password означає, що пароль неможливо вгадати, а доступ до облікового запису здійснюється через sudo -u agent або SSH-ключ. Зверніть увагу: agent навмисно не входить до групи sudo. Агент із sudo має права root, а root може читати файли всіх інших користувачів. У такому разі створене розмежування є лише формальністю. Якщо агент справді має встановлювати пакети, це аргумент на користь окремого сервера, яким він володіє, а не надання йому sudo на спільному сервері. Загальні правила наведено в матеріалі мінімальні привілеї для користувачів Linux на VPS.

Перевірте межі доступу, перш ніж довіряти цьому налаштуванню. Від імені користувача agent спробуйте вивести список файлів у домашньому каталозі власного облікового запису:

sudo -u agent ls /home/you

Ви маєте побачити ls: cannot open directory '/home/you': Permission denied. Якщо замість цього відображається список файлів, інші користувачі можуть читати ваш домашній каталог, а агент може читати всі файли в ньому, доступ до яких окремо не обмежено, наприклад загальнодоступний файл .env. Виправте це за допомогою sudo chmod 700 /home/you. Ця перевірка не захищає ваш приватний SSH-ключ: ssh ігнорує файл приватного ключа, до якого мають доступ інші користувачі. Тому будь-який ключ, який справді працює для вас, уже недоступний для читання користувачу agent, незалежно від режиму доступу до домашнього каталогу.

Не зберігайте облікові дані на машині взагалі

Призначення disposable machine втрачається, якщо скопіювати на неї production secrets. Правило просте: на цій машині не повинно бути жодного credential, який ви не хотіли б відкликати вже сьогодні.

Для git передавайте SSH agent замість копіювання ключа. Приватний ключ залишається на вашому laptop, а через з’єднання передаються лише запити на підпис.

ssh -A agent@203.0.113.10
ssh -T git@github.com

Друга команда має повернути Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Це доводить, що git push працюватиме без файлу ключа на сервері. Після цього виконайте на машині ls -la ~/.ssh і переконайтеся, що приватного ключа на ній немає.

У forwarding агента є один важливий ризик, тому сформулюємо його прямо: поки ви підключені, будь-хто, хто має root на цьому сервері, може використати forwarded socket для автентифікації від вашого імені. На сервері, єдиним іншим користувачем якого єте ви, це прийнятний компроміс. На спільній машині — ні. У такому разі кращим варіантом буде deploy key з обмеженням доступу до одного репозиторію. Варіанти розглянуто в розділі Основи керування SSH-ключами.

Для API keys надайте агенту окремий ключ із власним лімітом витрат і збережіть його у файлі, власником якого є користувач agent, із mode 600. Коли машину буде знищено, відкличте цей ключ, а не намагайтеся з’ясувати, чи не стався витік. Відстеження витрат на model для кожного ключа також дає змогу зберігати прогнозованість показників у розділі Контроль витрат AI-агента на VPS.

Обмежте мережевий доступ агента

Ізоляція файлової системи — це лише половина межі. Друга половина — вихідний трафік: з якими вузлами процесу дозволено обмінюватися даними. Linux може фільтрувати вихідний трафік за користувачем, який його створив. Це саме відповідає цій схемі.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Правила читаються по порядку, тому останнє REJECT перехоплює все, що не дозволили попередні рядки. Перевірте це від імені агента:

sudo -u agent curl -sS -m 5 http://example.com

Команда одразу має завершитися помилкою curl: (7) Failed to connect to example.com. Точний текст залежить від версії curl, оскільки правило відхилення відповідає негайно, а не дає з’єднанню зависнути. HTTPS-запит до того самого вузла все одно має виконуватися успішно.

Є два важливі обмеження. По-перше, ці правила буде втрачено після наступного перезавантаження, якщо їх не зберегти за допомогою sudo apt install -y iptables-persistent, а потім sudo netfilter-persistent save. По-друге, вони фільтрують порти й адреси, а не імена. Правило, яке дозволяє порт 443, відкриває доступ до будь-якого HTTPS-вузла в інтернеті. Цього достатньо для доступу до API моделі, але також достатньо для доступу до pastebin. Для справжнього списку дозволених доменів трафік має проходити через проксі, яке читає запитане ім’я хоста. Для більшості конфігурацій одного розробника це зайва складність. Заявляйте лише те, що фактично налаштували: контроль вихідного трафіку на рівні портів на машині, яку ви були готові втратити.

Очищення стану між завданнями

Чистий стан для кожного завдання — недооцінена перевага. Агент, який три години працював над попереднім завданням, міг залишити після себе встановлені пакети, частково застосовані міграції, застарілий node_modules і робоче дерево git зі змінами, які ніхто не перевірив. Наступне завдання успадковує все це, і ви витрачаєте час на перевірку, з’ясовуючи, який безлад належить до якого запуску. Вузькоспеціалізований агент від самого початку залишає менше змін, тому поєднання одноразової машини з навичкою, яка спонукає агента вносити найменшу працездатну зміну дає змогу зберігати і diff, і залишковий стан достатньо малими для перевірки.

Найдешевший варіант — використовувати свіжий checkout для кожного завдання.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

Надійніший варіант — один раз створити snapshot провайдера одразу після налаштування машини й до того, як її торкнеться будь-який агент. Відновлення цього snapshot повертає всю систему, разом із пакетами, до відомого стану. Більшість провайдерів надає цю можливість у панелі керування або через API, а не як команду на самій машині, тому точні кроки залежать від вашого провайдера. Важливо створити snapshot, поки машина ще не використовувалася.

Зберігайте все важливе поза одноразовою машиною. Зазвичай це означає push гілок замість їхнього накопичення локально. Якщо на машині все ж опинилося щось, чию втрату ви помітите, належно створіть резервну копію за допомогою резервних копій restic на VPS. Машина, яку можна знищити, корисна лише тоді, коли її знищення справді не створює проблем.

Якщо вам потрібно кілька ізольованих середовищ без оплати кількох серверів, один потужніший VPS може безпосередньо розміщувати гостьові VM. У матеріалі Віртуалізація з вкладенням на VPS описано принцип роботи цієї схеми, зокрема перевірку того, чи дозволяє її ваш провайдер. Ізоляція має і зворотний бік: якщо ви хочете, щоб два агенти на одній машині координували роботу, а не були повністю ізольовані один від одного, одна сесія Claude Code може безпосередньо надсилати текст іншій замість маршрутизації кожної передачі через вас.

Коли ноутбук із належними обмеженнями справді підходить

Говоріть про це чесно, адже перебільшення переваг ізоляції призводить до того, що люди перестають слухати.

Якщо ви перевіряєте кожну команду перед її виконанням, ноутбук підходить. Запит на надання дозволу є реальним засобом контролю, а в матеріалі безпечний запуск Claude Code на сервері розглянуто, що саме блокує кожен його рівень. Якщо ви працюєте з одним репозиторієм і на комп’ютері ніде немає облікових даних production-середовища, потенційний масштаб наслідків уже невеликий. Якщо сеанси агента короткі й перебувають під вашим наглядом, період можливого впливу також короткий.

Ситуація змінюється, щойно ви пропускаєте ці запити. Це особливо важливо тепер, коли автоматичний режим є типовим режимом Claude Code, а нова інсталяція більше не запитує дозволу перед редагуванням файлів або виконанням команд. Неконтрольовані запуски, нічні завдання та будь-який робочий процес, у якому ви схвалюєте план і відходите від комп’ютера, усувають перевірку людиною, яка забезпечувала стримування. Тоді це має робити сама система. Те саме стосується всього, що розширює доступ агента, зокрема запуску агента програмування на VPS для одночасної роботи з кількома репозиторіями.

Рішення насправді залежить не від того, наскільки ви довіряєте моделі. Воно залежить від того, що буде поруч із нею, коли модель помилиться.

FAQ

Чи достатньо контейнера для ізоляції coding agent?

Для більшості завдань — так, за двох умов. Контейнер не має запускатися з --privileged і не повинен мати змонтований у нього /var/run/docker.sock, оскільки будь-який із цих варіантів дає процесу шлях до root на хості. Контейнер використовує ядро хоста, тому цей бар’єр слабший, ніж у віртуальної машини. Якщо agent запускає ненадійний код, отриманий з інтернету, використовуйте повноцінну VM або окремий сервер.

Чи потрібен agent доступ до sudo на сервері?

Ні. Надання доступу до sudo нівелює створену ізоляцію, оскільки root може читати дані всіх інших облікових записів на сервері. Створіть користувача для agent без sudo і надайте йому доступ на запис лише до власного робочого каталогу. Якщо завдання справді потребує встановлення пакетів, виділіть agent окрему машину, якою він володіє, а не root-доступ на машині, спільній з іншими процесами.

Як дозволити agent виконувати push у git, не розміщуючи мій SSH-ключ на сервері?

Під час підключення передайте SSH agent за допомогою ssh -A. Запити на підпис проходять через з’єднання, а приватний ключ залишається на вашому ноутбуці, тому ssh -T git@github.com виконує автентифікацію, а git push працює без приватного ключа на сервері. Однак root на цьому сервері може використовувати переспрямований сокет, поки ви підключені. Тому на будь-якій машині, спільній з іншими користувачами, використовуйте deploy key з обмеженням на конкретний репозиторій.

Який розмір VPS потрібен agent?

Робота agent здебільшого полягає в редагуванні файлів, запуску збірок і тестів, тому розмір машини слід визначати за вимогами збірки, а не моделі. Hosted model працює на обладнанні провайдера, що створює мережевий трафік і майже не навантажує локальну машину. Сам agent все одно визначає мінімальні вимоги: станом на October 20, 2026, у системних вимогах Claude Code зазначено 4 GB RAM як мінімум. Почніть із 4 GB навіть для роботи зі скриптами та перейдіть на 8 GB, якщо репозиторій збирає контейнери або компілює щось значне.

Як часто потрібно знищувати та перебудовувати машину?

Перебудовуйте машину, коли її стан більше неможливо пояснити, і щонайменше щоразу, коли облікові дані на ній могли бути розкриті. Свіже клонування репозиторію перед кожним завданням усуває повсякденні зміни, а snapshot, створений перед першим запуском agent, дає змогу повернутися до чистого образу системи. Якщо перебудова здається надто витратною, це означає, що на машині, яку ви назвали disposable, зберігаються важливі дані або стани.