Сандбокс для Claude Code: ізольовані середовища агентів на ноутбуці

Коли перезавантаження стирає вашу робочу пам’ять

Уявіть собі шість чи сім сеансів Claude Code, які працюють одночасно. Деякі з них відкриті у терміналах, кілька — у VS Code, ще один працює в IntelliJ, адже команда використовує кілька мов програмування, і у кожної є свій улюблений редактор. Вони працюють з різними репозиторіями, виконують різні завдання та опрацьовують різні незавершені ідеї. Потім ноутбук перезавантажується.

У самому коді немає жодних проблем. Проблема полягає у втраті інформації про стан роботи: який сеанс був у процесі оптимізації, який чекав на збірку, а в якому було поставлено запитання, відповідь на яке так і не була прочитана. На відновлення робочої пам’яті з історії командних рядків та недосконалих гілок Git йде двадцять хвилин. У цей момент поганий день починає здаватися проблемою проектування.

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

Шафлінг. Агенти дешево запускаються, але їх ведення є дорогим. Кожен новий агент потребує окремої вкладки терміналу, окремого вікна редактора, ще однієї „дірки“ у вашій пам’яті. Ноутбук перетворюється на купу вікон, де єдиним елементом інтеграції є людина. Існуючі інструменти передбачають наявність одного агента, одного завдання та однієї людини, яка за ним стежить, але робота відбувається не так.

Дилема дозволів. У стандартній налаштовці немає рішення цієї проблеми. Claude Code вимагає схвалення для кожного виклику інструменту, проте може запитати у вас про щось дрібне, залишаючись мовчазним щодо виклику, який може завдати серйозної шкоди. Поведінка покращилась, але основна проблема залишилася незмінною, адже агент діє від вашого імені та має ваші привілеї. Адміністратор GitHub-організації не може розумно схвалювати кожен виклик API, а також не може прикидатися, що одноразове схвалення є безневинним.

Залишається два варіанти. Ви можете продовжувати налаштовувати список дозволів, поки він не перетвориться на такий складний для розшифрування документ, що жоден колега не зможе його прочитати, або ж можна увімкнути параметр --dangerously-skip-permissions та покластися на удачу. Жахливі історії пов’язані саме з другим варіантом, наприклад із агентом, який енергійно очищував базу даних у продакшн-середовищі. Обидва підходи провалюються з однієї причини: агент несе вашу ідентичність, і схвалення команд по одній допомагає подолати лише цю проблему.

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

Окрема машина для агента

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

Колеги помітили це та попросили свої власні версії, потім зробили те саме й інші. Цей інструмент вийшов за межі свого початкового призначення як засіб однієї людини та тепер щоранку з’являється на екранах все більшої кількості інженерів — від кількох перших користувачів до кількох десятків, причому більшість членів інженерної команди, ймовірно, скоро приєднаються. Ніхто не змушує користуватися ним; люди приймають його тому, що тиждень стає легшим, що є єдиним переконливим ознакою прийняття. Новий співробітник встановлює Capsule на ноутбук та може повністю працювати автономно вже з першого дня.

Одним словом, Capsule надає Claude Code ізольовану, готову сандбокс-середовище, де він може самостійно працювати з вашими репозиторіями, тож більше не працює з усіма вашими привілеями.

На зображенні показана станція Capsule Station. Капсули відображені вздовж лівого краю, термінал обраного агента знаходиться посередині, а запити на створення нових версій, якими ви керуєте або які вам потрібно переглянути, — у нижньому лівому кутку, що забезпечує одне вікно для всього флоту.

Його функціонал навмисно обмежений. Це не фреймворк для оркестрації агентів чи продукт для кількох агентів, принаймні поки що, хоча можлива оркестрація з’явиться незабаром. Це не інтеграція з IDE, плагінами чи редактором, і воно не є форком чи заміною Claude Code, адже те, що працює всередині, — це звичайний Claude Code, налаштований певним чином. Воно не замінює системи CI/CD та не є SaaS-сервісом, оскільки все відбувається на вашому ноутбуці.

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

Усередині капсули Claude працює з параметром --dangerously-skip-permissions та ніколи не запитує, чи може виконати певну команду. Його єдині запитання стосуються мети, тобто того, що потрібно зробити, а не дозволів. Такий розумний стандарт існує лише завдяки двом факторам, які лежать в основі.

Пісочниця

Кожна капсула функціонує як под у кластері Kubernetes, який OrbStack вже надає на Mac. Це забезпечує повну локалізацію процесів без додаткової інфраструктури та без оплати за користування хмарою. До файлової системи хоста неможливо отримати доступ, а два оголошені об’єми зберігають постійні дані: робочу зону та кеш образів Docker. Три шари обмежують вихідний трафік:

• Правила iptables ядра блокують прямий вихідний трафік на порти 80 та 443 для ідентифікатора користувача агента.
• Політика мережі Kubernetes NetworkPolicy звужує можливості до DNS, портів 80 та 443.
• Усе, що залишилося, проходить через проксі Squid, який дотримується чіткого списку дозволених доменів.

Список дозволених доменів включає GitHub, npm, Maven, ECR та API Anthropic; усі інші адреси за замовчуванням заборонені. У агента немає простого способу для доступу до довільного кінцевого пункту та завантаження вихідних даних, а досягнення цього вимагатиме справжньої кмітливості.

Три рівні перешкоджають виходу будь-чого назовні: правила ядра, потім політика мережі та нарешті проксі з списком дозволених запитів.

Облікові дані з мінімальними привілеями

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

• тимчасові облікові дані AWS STS, обмежені роллю лише для читання в продакшн-середовищі
• токен GitHub, чий діапазон прав перевіряється перед використанням
• обліковий запис служби BigQuery лише для читання, під виглядом якого працює агент, щоб ваші власні облікові дані не були залучені

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

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

Усунення перешкод

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

Основне зображення, з якого запускаються капсули, вже містить закріплені версії інструментальних комплексів: Go, Rust, Node, JDK, Maven, sbt та Scala. Разом з ним працює Docker-in-Docker sidecar, який забезпечує кожній капсулі власний робочий Docker, тож інтеграційні тести та набори Testcontainers виконуються без впливу на сусідні капсули. Також доступні інструменти командного рядка з автологіном, а саме GitHub CLI, AWS CLI, gcloud та bq. Вже з початку є сервери мов (Metals, jdtls, gopls, rust-analyzer, vtsls), які дозволяють агенту пересуватися по коду за допомогою функцій go-to-definition, find-references та визначення ієрархій викликів замість сліпого пошуку.

Кеші залежностей діляться між капсулами через об’єм хоста. Це здається дрібною деталлю, але це не так. У першій версії кожне нове середовище завантажувало все заново, і інструмент, який витрачає двадцять хвилин на обробку Maven перед кожним завданням, не міг бути прийнятий. Тепер готова капсула створюється приблизно за двадцять–тридцять секунд.

Найбільше поведінку агента змінив справжній цикл зворотного зв’язку. Усередині капсули працює внутрішня платформа CLI: перевіряється токен SSO хоста, обмежується його діапазон та вводиться, що дозволяє агенту створити середовище сандбокс, розгорнути відповідну гілку коду та провести там тести на коректність функціонування. Також усередині працює інструментарій для тестування інтеграції, який завантажує реальні зображення та запускає справжні сервери MySQL, Kafka та Cassandra у компоненті sidecar. Спочатку процес є повільним через обробку зображень через проксі, але пізніше він стає швидким. Саме це відрізняє агента, який створює правдоподібний код, від того, хто може повідомити, чи цей код справді працює.

Функція пошуку також є вбудованою. Кожна капсула починається з внутрішнього шлюзу MCP, який дозволяє лише читати та надає кілька десятків інструментів. Вони дають доступ до журналів подій сервісів та подів, метрик через PromQL та Thanos, панелей керування Grafana, подій Kubernetes, статусу процесів CI, інформації про те, хто знаходиться у режимі чергування та які сповіщення активні, інформації про власників сервісів, а також можливості пошуку в Confluence та Slack. Оскільки нічого не можна було записувати, його увімкнення всюди не несло жодних ризиків. Ринок плагінів додає функції для роботи з проектами Maven, створення схем сервісів, керування сандбоксами та перегляду змін, тож агент вже з першої хвилини знайомий із стандартами компанії.

Ось звичка, яку варто прийняти. Тримайте приватний репозиторій із особистими командами та шаблонами планів, і Capsule клонуватиме його у кожне створене середовище. Таким чином ваш власний робочий процес буде супроводжувати вас. Плани та записи також переміщуються між „капсулами“ через цей репозиторій, а функція передачі інформації дозволяє вказати, де закінчилася сесія, та зберегти її узагальнення, щоб наступна „капсула“ починала роботу з уже наявною інформацією, а не з нуля. Це звичайний git-репозиторій, тож агент також може підтримувати власні інструменти, і достатньо лише однієї команди на кшталт „додай команду для збірки та тестування, збережи її, відправь“.

Зберігання краще за початок

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

У звичайний день активними є чотири чи п’ять капсул. Одна працює без керування над виправленням помилок, інша — це сесія SSH для справжнього парного програмування, ще одна перезапускає нестабільний тест інтеграції та створює запит на з’єднання після його проходження, а четверта поступово вирішує проблему з залежностями, яку ніхто не хоче стежити. Ще близько десяти капсул знаходяться у зупиненому стані: ідея, до якої можна повернутися, експеримент, який провалився цікавим чином, частково розглянутий дизайн. Зупинка зберігає репозиторії, сесії та кеш, а відновлення займає кілька секунд, тож ідея не залишається нереалізованою лише через те, що вона не є пріоритетом сьогодні.

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

Повна автономія усуває залишкове тертя. Немає необхідності у підтвердженні команди git, не потрібно шукати номер на сторінці CI у вкладці браузера чи переглядати журнал збірки у пошуках важливої рядка. Агент сам усе обробляє, а завдяки сандбоксу та обмеженим токенам це не перетворюється на просту азартну гру.

Чотири капсули, чотири стани — жоден з них не чекає на людину.

У одному двигуні є два режими. Ви можете працювати разом з агентом у інтерактивній сесії tmux чи просто надати йому команду та залишити все як є.

Ось чому інтерфейс є ефективним. CLI є потужним, проте постійне виконання команд list, ssh та status у терміналі — це не спосіб керування флотом. Capsule Station заповнює цю прогалину за допомогою одного вікна: капсули у бічній панелі, вбудований термінал для кожної з них, а також запити на отримання коду та перевірку поруч. Зміна агентів схожа на зміну вкладок у браузері. Додаток використовує Tauri, його розмір становить близько десяти мегабайт, і він спирається на системний webview, адже відображення списку не повинно вимагати вбудованого Chromium та гігабайта дискового простору. Він зазвичай залишається відкритим протягом усього дня, на відміну від IDE.

Не менш справедливо сказати, що залишається недоторканим. Якість генерованого коду не покращується. Те, що зникає, — це всі пов’язані з цим клопоти: переміщення, схвалення, встановлення, повторна автентифікація та втрата місця, що, як виявилося, становить більшу частину труднощів.

Чому краще створювати, ніж купувати

Варіанти хостингу справді існують та стають все кращими — це, наприклад, пісочниці у форматі хмарних агентів від різних постачальників та агенти, які працюють віддалено за вашими інструкціями. Вони не створюють операційних труднощів та забезпечують справжню масштабованість. Однак код та облікові дані залишаються поза вашими системами, інструментарії є універсальними, тож початок роботи з великою базою коду затягується, а внутрішня модель ідентифікації не може бути реалізована. Існують також проекти з відкритим кодом, як-от пісочниці, створені спеціально для Kubernetes, інструменти типу dev-container та примітиви локального пісочницювання, які надають постачальники. Вони є нейтральними щодо постачальників та побудовані на міцних основах, проте є низькорівневими, тож ви самі несете відповідальність за образи, автентифікацію та всю користувацьку інтерфейс. У будь-якому випадку виникає закономірне питання: чи буде цей варіант підтримуватися через шість місяців, адже кожен починає свої проекти, але мало хто з них триває довго.

Ця структура розташована між цими двома компонентами. Капсула переважно є складовою конфігурації: DevPod керує життєвим циклом контейнера для розробки та самого пода, Squid забезпечує вихідний трафік, використовується кластер Kubernetes, який вже надає OrbStack, а також існує власне зображення робочого простору, автентифікація через хост та Station як верхній шар. Залежність залишається незначною, і компоненти можна замінити. Це підходить до поточної бази коду та моделі автентифікації, причому код залишається на ноутбуці, окрім того, що агент надсилає до API моделі — як і у всіх інших варіантах.

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

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

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

Що буде далі

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

Попередження щодо прогалин у безпеці

Система свідомо спрямована на захист, і її створення дарує неприємний урок: інструмент, який надає агентам автономію, найбільше покладається на слабкі місця моделі безпеки. Хороший контроль доступу полегшує інтеграцію, тоді як його відсутність шкодить відразу та чітко показує причини.

Проте у «пісочниці» є обмеження. Робота агента з повними привілеями схожа на носіння зарядженої зброї, незалежно від того, чи буде вона використана. Capsule усуває ці проблеми. Однак, якщо вставити токен адміністратора у чат та попросити агента ним скористатися, привілеї знову повертаються.

Почніть створювати

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