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

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

За замовчуванням Claude Code запитує підтвердження перед виконанням дій. Читання файлів у межах проєкту відбувається без повідомлень, але перед редагуванням файлу або виконанням shell-команди Claude Code спочатку показує точну зміну чи команду й чекає підтвердження. Можна схвалити одну дію або дозволити такий тип дій до кінця сеансу. Ці дозволи діють лише в межах сеансу: після виходу з CLI наступний сеанс знову починається в обережному режимі. Для правил, які мають зберігатися, файл налаштувань містить постійні списки allow, ask і deny. Наприклад: дозволити git status, запитувати підтвердження для git push, заборонити читання .env. Правила deny завжди мають пріоритет. Ця базова поведінка також змінюється, оскільки 14 August 2026 auto mode стане режимом за замовчуванням. Тому перед вибором режиму для сервера, за яким неможливо стежити, варто знати що саме дозволяє кожен режим доступу.

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

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

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

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

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

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

Перш ніж переходити до рівнів, зверніть увагу: Claude Code тепер має sandbox на рівні ОС для команд, які він запускає. Це усуває більшість причин, через які раніше використовували skip flag. У 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 flag: ви отримуєте значно менше запитів завдяки межі, яку контролює ОС, а не повній відсутності перевірок.

Реалістично оцінюйте його обмеження. За замовчуванням команда в 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 лише агенту. Збережіть його у файлі, власником якого є користувач агента, і встановіть режим доступу 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 домашні каталоги часто створюються доступними для читання всім користувачам системи, тому обмежте доступ до власного каталогу: chmod 750 /home/youruser. Перевірте результат за допомогою ls -ld /home/* і виправте все, що обліковий запис агента може переглядати.

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

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

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

git switch -c agent/refactor-auth

Після завершення роботи перегляньте результат за допомогою git diff main...agent/refactor-auth, об’єднайте корисні зміни та видаліть гілку, якщо результат не має цінності. Результат, у якому змінено три файли, значно легше переглянути вранці, ніж результат, у якому переписано половину модуля. Саме тому практично використовувати навичку, яка обмежує агента найменшою зміною, що вирішує проблему. Захистіть головну гілку на боці 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, не зачіпаючи жодного іншого вашого ресурсу.