Як безпечно запускати Claude Code на сервері

Що означає безпечно запускати Claude Code на сервері

Щоб безпечно запускати Claude Code на сервері, залиште запити на підтвердження дозволів увімкненими, запускайте його від імені окремого непривілейованого користувача та забезпечте для автоматичних запусків реальне обмеження, а не просто довіру: вбудований sandbox, контейнер або одноразовий VPS, у якому немає важливих для вас даних. Прапорець --dangerously-skip-permissions прибирає етап підтвердження між моделлю та вашою оболонкою. Такий компроміс може бути прийнятним для автоматичних завдань, але лише в межах, які обмежують наслідки однієї небезпечної команди. У цьому посібнику пояснюється, що саме змінює цей прапорець і як створити таке обмеження з рівнями ізоляції, що поступово посилюються.

Що Claude Code може робити на вашому сервері

Claude Code — це coding agent, який працює в терміналі. Він читає файли, записує файли та виконує shell-команди від імені користувача, який його запустив. У цьому полягає основна цінність інструмента: він може клонувати репозиторій, редагувати код, запускати тести, читати повідомлення про помилки та циклічно виправляти код без введення кожної команди вручну. Якщо ви ще не налаштували його на сервері, у матеріалі запуск Claude Code на VPS за допомогою tmux описано встановлення та керування сесіями. На цій сторінці описано, які можливості ви надаєте йому після встановлення.

Ризик стає очевидним, якщо повторити це речення. Процес, який виконує shell-команди від імені вашого користувача, може робити все, що доступно цьому користувачу. Він може читати ~/.ssh/id_ed25519, ~/.aws/credentials і всі файли .env, до яких ваш користувач має доступ. Він може виконувати curl і надсилати дані на будь-який хост, доступний із сервера. Він може виконувати git push --force. Агент не має власних мотивів. Небезпека полягає в тому, що завдання може виконуватися неправильно або що текст, прочитаний під час роботи, міститиме інструкції, написані іншою особою: наприклад, вебсторінка, яку він завантажив, або коментар в issue, який його попросили виправити. Другий випадок називається prompt injection. Саме тому твердження «модель зазвичай діє розсудливо» не може бути планом безпеки. Інструкції можуть надходити й із ближчого джерела, оскільки дві сесії Claude Code на одному сервері можуть надсилати текст одна одній, а повідомлення від іншої сесії — це лише додатковий текст, який читає агент-одержувач. Плануйте захист від небезпечного запуску, а не від середнього сценарію.

Система дозволів простими словами

У режимі Manual Claude Code запитує підтвердження перед виконанням дій. Читання файлів у межах проєкту відбувається без запиту, але перед редагуванням файлу або виконанням shell-команди Claude Code показує точну зміну чи команду та очікує підтвердження. Можна схвалити одну дію або вказати більше не запитувати підтвердження. Для редагування файлів другий вибір діє до завершення сеансу, а для shell-команди зберігається постійно для цього репозиторію та команди. Тому швидке підтвердження на сервері діятиме й після завершення сеансу. Правила, які потрібно зберігати явно, задаються у файлі налаштувань у вигляді постійних списків allow, ask і deny. Наприклад: дозволити git status, запитувати підтвердження для git push, заборонити читання .env. Правила deny завжди мають пріоритет. Ця базова схема також змінилася. У режимі Auto класифікатор перевіряє дії замість вас. Для нових сеансів у планах Pro, Max і Team цей режим став типовим 14 August 2026, а починаючи з Claude Code v2.1.283 він є вбудованим стартовим режимом для інтерактивних сеансів у terminal і VS Code на всіх планах, якщо ви не зафіксували інший режим за замовчуванням. Тому перед вибором режиму для сервера, за яким ви не можете стежити, варто знати що насправді дозволяє кожен режим дозволів.

Ця схема передбачає, що людина стежить за terminal. На laptop це зазвичай так. На сервері часто саме ніхто не стежить за виконанням. Ви запускаєте тривале завдання всередині tmux і лягаєте спати. Якщо агент зупиняється, щоб поставити запитання о 2 a.m., робота не продовжується до ранку. Пауза коштує не лише часу, а й грошей, оскільки неактивний сеанс Claude Code втрачає прогрітий prompt cache, а наступний крок потребує повторного його створення. Це реальна причина, через яку на серверах використовують прапорець skip, і проблему він справді вирішує. Решта цього посібника присвячена тому, як розв’язати її, не відмовляючись від усіх механізмів захисту.

Що змінює --dangerously-skip-permissions

claude --dangerously-skip-permissions вимикає етап підтвердження. Зміни відбуваються без запиту. Команди shell виконуються без запиту. Перевірки захищених шляхів, які зазвичай захищають чутливі розташування, також пропускаються. Явно задані правила deny продовжують діяти, а для деяких потенційно небезпечних дій підтвердження все ще запитується, але загальний принцип простий: усе, що модель вирішує виконати, виконується.

На сервері важливі два факти про цей прапорець. По-перше, його заблоковано, коли Claude Code запускається від root або через sudo у Linux і macOS, оскільки root без підтверджень може змінити будь-який файл або сервіс на машині. Агенту все одно потрібен окремий непривілейований обліковий запис, і цей прапорець забезпечує таку вимогу. По-друге, прапорець жодним чином не змінює поведінку моделі. Він лише усуває людину з циклу виконання і не змінює нічого іншого, тому кожна помилка, яку раніше міг зупинити запит на підтвердження, тепер виконується.

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

Вбудований sandbox Claude Code

Перш ніж переходити до рівнів, варто знати: Claude Code тепер має sandbox на рівні ОС для команд, які він виконує. Це усуває більшість причин використовувати прапорець skip. У Linux для ізоляції файлової системи він використовує bubblewrap, а socat спрямовує мережевий трафік через проксі. Усередині sandbox команда може записувати дані лише до каталогу проєкту та тимчасового каталогу сеансу. Доступ до мережі можливий лише через проксі, який перевіряє кожен домен за списком дозволених. Коли команда вперше звертається до нового домену, Claude Code запитує дозвіл. В автоматичному режимі класифікатор натомість перевіряє новий хост.

Увімкніть його командою /sandbox у межах сеансу. В Ubuntu та Debian спочатку встановіть два потрібні пакети:

sudo apt install bubblewrap socat

В Ubuntu 24.04 і новіших версіях стандартна політика AppArmor не дозволяє bubblewrap створювати потрібні йому користувацькі простори імен. Панель sandbox повідомляє, коли чогось бракує. У документації Claude Code про sandbox наведено короткий профіль AppArmor, який це виправляє.

У sandbox є режим автоматичного дозволу: команди в sandbox виконуються без запиту, оскільки тепер роботу запиту виконує примусово встановлена межа. Команди, які не можуть виконуватися всередині sandbox, переходять до звичайного процесу перевірки дозволів. Тому справді нетипові дії все одно потребують підтвердження. Для більшості серверних сценаріїв це правильна заміна прапорця skip: запитів стає значно менше, але межа ізоляції забезпечується на рівні ОС, а не просто відсутня.

Важливо об’єктивно оцінювати обмеження. За замовчуванням команда в sandbox усе ще може читати більшість файлової системи, зокрема файли облікових даних, якщо явно не заборонити доступ до цих шляхів. Саме для цього існує параметр sandbox.credentials. Мережевий проксі перевіряє імена доменів, але не аналізує сам трафік. Тому широке правило дозволу, наприклад github.com, усе ще дає змогу вивести дані назовні. Docker усередині sandbox не працює. Sandbox суттєво підвищує базовий рівень захисту. Але це не повна межа ізоляції, тому наведені нижче рівні все одно важливі.

Рівні ізоляції

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

Рівень 1: окремий непривілейований користувач. Агент отримує власний обліковий запис, власний домашній каталог, власний каталог проєкту та не має доступу до sudo:

sudo adduser --disabled-password --gecos "" agent

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

Рівень 2: контейнер. Anthropic публікує reference devcontainer, у якому Claude Code працює від імені користувача без root, а правила firewall обмежують хости, до яких агент може підключатися. Контейнер, який ви створюєте самостійно, виконує те саме завдання. Файлова система обмежується змонтованими томами, а вихідні з’єднання — тим, що дозволяють правила контейнера. Це оптимальний середній рівень, якщо на сервері працюють інші важливі для вас сервіси. Обмеження полягає в тому, що контейнери використовують спільне ядро хоста, а необережне монтування скасовує цю межу; передайте контейнеру /var/run/docker.sock, і він отримає доступ до всього хоста.

Рівень 3: окремий VPS. Найсильніший рівень є найпростішим: виділіть агенту цілу машину, на якій немає нічого важливого для вас. Невеликий VPS коштує кілька доларів на місяць. Налаштуйте його за інструкцією для перших десяти хвилин на новому VPS, створіть snapshot чистого стану та дозвольте агенту працювати. На цій машині більше нічого немає. Жодного особистого SSH-ключа — лише deploy key з обмеженням доступу до одного репозиторію. Жодних облікових даних хмарних сервісів і виробничих даних. Якщо виконання завершилося помилкою або вам просто потрібен чистий стан, відновіть snapshot чи знищіть і перебудуйте сервер за кілька хвилин. Радіус ураження обмежується вартістю оренди. У такій конфігурації --dangerously-skip-permissions більше не лякає, оскільки найгірший реалістичний наслідок — відновлений сервер і один відкликаний токен.

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

Захистіть облікові дані

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

Надайте API key лише агенту. Збережіть його у файлі, власником якого є користувач агента, із mode 600, і завантажуйте його під час запуску shell:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Потім закрийте доступ у зворотному напрямку. У старих інсталяціях Debian і Ubuntu, а також для облікового запису, створеного під час інсталяції, home directories можуть бути доступними для читання всім користувачам системи. Тому обмежте доступ до власного каталогу: chmod 750 /home/youruser. Перевірте результат за допомогою ls -ld /home/* і виправте все, що обліковий запис агента може переглядати.

Обмежуйте область дії кожного token. GitHub token із детальними дозволами, обмежений одним repository, або deploy key для окремого repository означає, що в разі витоку облікових даних буде скомпрометовано один проект, а не весь обліковий запис. Якщо ви використовуєте sandbox, додайте його параметри облікових даних, щоб ~/.ssh і ~/.aws були заборонені навіть для операцій читання. Не зберігайте production credentials на цьому сервері взагалі: агент не може розкрити секрет, якого на сервері ніколи не було. Якщо ці секрети зберігаються в self-hosted password manager, розмістіть його на іншому сервері, окремо від агента, і проведіть для нього окремий аудит, оскільки слабкі місця Vaultwarden — admin token і backup file, а не зашифрований vault.

Git — це страховка

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

git switch -c agent/refactor-auth

Зміни, які агент не фіксує комітом, такого захисту не мають: команда git reset --hard скасовує незакомічені зміни у відстежуваних файлах, а git взагалі не охоплює нічого за межами репозиторію. Після завершення перевірте результат за допомогою git diff main...agent/refactor-auth, щоб побачити, що агент закомітив, а потім виконайте git status і git diff HEAD у гілці, щоб знайти зміни, які він залишив незакоміченими. Залиште потрібні зміни, а гілку видаліть, якщо результат не має користі. Результат запуску, під час якого змінено три файли, набагато легше переглянути за сніданком, ніж результат, у якому переписано половину модуля. Саме для цього потрібна навичка, яка обмежує агента найменшою зміною, достатньою для роботи. Захистіть основну гілку на стороні forge, щоб токен агента не міг виконувати push до неї та не міг виконувати force-push у жодну гілку. Історія комітів одночасно є журналом аудиту подій, що відбулися, поки ви спали. Це цінніше за будь-який обсяг прокручування термінала.

Мережа є частиною зони ураження

Агент може виконати curl. У цьому полягає вся проблема вихідного трафіку: усе, що агент може прочитати, він також може надіслати в інше місце, особливо якщо його запит було скомпрометовано через prompt injection. Звичайний непривілейований користувач не обмежує це взагалі, оскільки будь-який користувач може отримати доступ до всього, до чого має доступ сервер. Пісочниця обмежує доступ до мережі за доменами через свій проксі. Контейнер може обмежувати його власними правилами firewall. Виділений VPS із самого початку обмежує обсяг даних, які можна витікати, і це найнадійніший із трьох варіантів.

Не намагайтеся вирішити проблему вихідного трафіку лише за допомогою ufw. За замовчуванням ufw дозволяє весь вихідний трафік, а створення правил для вихідних з’єднань, які водночас дозволяють apt, npm, git і Claude API, є складним завданням. Такі правила можуть непомітно перестати працювати. Визначайте межу на рівні пісочниці, контейнера або машини. На цьому рівні список дозволених доменів або окрема машина виконує те саме завдання надійно й без зайвої складності.

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

Спочатку захистіть сервер

Незалежно від обраного рівня сам сервер потрібно спочатку належно підготувати, перш ніж розгортати на ньому агент: дозволити лише SSH-ключі, заборонити вхід для root, налаштувати брандмауер із політикою default-deny і ввімкнути автоматичне встановлення оновлень безпеки. Створіть тут свій контрольний список і один раз пройдіть його зверху вниз:

FAQ

Чи безпечно використовувати --dangerously-skip-permissions на сервері?

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

Чи має Claude Code sandbox?

Так. Claude Code постачається з вбудованим sandbox для shell-команд, який запускається командою /sandbox. У Linux він використовує bubblewrap, а в macOS — Seatbelt, обмежує запис каталогом проєкту та спрямовує мережевий доступ через proxy, який дозволяє лише схвалені домени. Його режим автоматичного дозволу виконує команди в sandbox без запитів на підтвердження. Тому він зменшує кількість переривань так само, як і прапорець пропуску, але зберігає межу, яку забезпечує операційна система. Це не повна межа ізоляції, тому для автономних запусків поєднуйте його з окремим користувачем або окремою машиною.

Чому прапорець пропуску відмовляється працювати від імені root?

Тому що root без запитів на підтвердження може змінити будь-який файл і будь-який сервіс у системі. Через це Claude Code блокує --dangerously-skip-permissions, якщо він працює від імені root або через sudo у Linux і macOS. Не намагайтеся обходити цю перевірку. Створіть для агента непривілейованого користувача й запускайте його від цього імені. Межа облікового запису є першим і найдешевшим рівнем ізоляції.

Чи може Claude Code читати мої SSH-ключі та файли .env?

Він може читати все, до чого має доступ користувач, від імені якого працює. Навіть стандартна політика sandbox дозволяє читати шляхи до облікових даних, доки ви явно не забороните це. Тому запускайте агента від імені окремого користувача, встановіть для власного домашнього каталогу права 750 або суворіші, забороніть шляхи до облікових даних у налаштуваннях sandbox і взагалі не зберігайте production-секрети на цій машині. Секрет, якого машина ніколи не містила, неможливо прочитати або викрасти.

Який найбезпечніший спосіб запускати Claude Code без нагляду?

Недорогий виділений VPS, який використовується лише для роботи агента: за десять хвилин його можна захистити, створити чистий snapshot і запускати Claude Code від імені непривілейованого користувача з увімкненим sandbox, API-ключем у файлі з правами mode-600, окремим deploy key для кожного репозиторію та всією роботою у гілках, які ви перевіряєте перед злиттям. Якщо запуск завершиться неправильно, ви відкликаєте один токен і відновлюєте snapshot, не зачіпаючи жодного іншого вашого ресурсу.