Запускайте 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, зокрема ті, що містять рядки підключення до production у локальному env-файлі. До нього також належить історія shell, у якій можуть залишатися токени, вставлені вами лише один раз. Крім того, агент має доступ до мережі, до якої підключений ваш ноутбук. Часто це домашня або офісна мережа з неавтентифікованими сервісами.

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

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

Математика вартості нудна — у цьому й полягає сенс

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

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

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

Станом на липень 2026 року

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

Локальна micro VM. Інструменти цієї категорії запускають справжню віртуальну машину на вашому обладнанні, монтують у неї репозиторій і надають агенту права 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 повністю вимикає для нього мережу. Це хороший варіант за замовчуванням для збирання або тестового запуску. Важливо розуміти, чого цей підхід не забезпечує: контейнер використовує ядро хост-системи, тому вразливість ядра може стати способом обійти ізоляцію. Межа ізоляції також зникає, щойно ви додаєте --privileged або монтуєте /var/run/docker.sock, щоб агент міг «використовувати Docker». Монтування Docker socket у контейнер рівнозначне наданню цьому контейнеру прав root на хості.

Звичайний VPS, який можна перебудувати. Не потрібен новий інструмент, є справжня ізоляція на рівні ядра, 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 cat /home/you/.ssh/id_ed25519

Ви маєте побачити cat: /home/you/.ssh/id_ed25519: Permission denied. Якщо замість цього відображається матеріал ключів, ваш домашній каталог має режим 755, і ізоляція ще не працює належним чином. Виправте це за допомогою sudo chmod 700 /home/you.

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

Призначення 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 port 80: Connection refused, оскільки правило reject негайно відповідає на запит, а не залишає з’єднання в очікуванні. HTTPS-запит до того самого хоста все одно має виконуватися успішно.

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

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

Чистий стан для кожного завдання — недооцінена перевага. Агент, який три години працював над попереднім завданням, міг залишити після себе встановлені пакети, частково застосовані міграції, застарілий 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-середовища, потенційний масштаб наслідків уже невеликий. Якщо сеанси агента короткі та контрольовані, вікно ризику також коротке.

Ситуація змінюється, щойно ви пропускаєте запити дозволу. Про це варто подумати зараз, оскільки 14 August 2026 auto mode стане режимом Claude Code за замовчуванням, і нова інсталяція більше не запитує дозволу перед редагуванням файлів або виконанням команд. Неконтрольовані запуски, нічні завдання та будь-який робочий процес, у якому ви схвалюєте план і відходите, усувають перевірку людиною, яка забезпечувала стримування. Тоді це має робити сама машина. Те саме стосується всього, що розширює доступ агента, зокрема запуску coding agent на 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 з обмеженням на конкретний repository.

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

Робота agent здебільшого полягає в редагуванні файлів, запуску build і тестів, тому розмір машини визначайте за вимогами build, а не моделі. Hosted model працює на обладнанні провайдера, що додає network traffic і майже не створює локального навантаження. Для роботи зі скриптами почніть із 2 GB RAM і перейдіть на 8 GB, якщо repository збирає контейнери або компілює щось значне.

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

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