Как запускать Claude Code без присмотра и не пожалеть

Начните с машины, а не с флагов

Все ограничения ниже проще, когда агент работает на машине, где больше ничего нет. На вашем ноутбуке «разрешить всё» означает вашу почту, менеджер паролей, учётные данные от продакшена и фотографии. На выделенной машине с одним репозиторием и одним ограниченным токеном «разрешить всё» означает этот репозиторий и этот токен. Anthropic сама рекомендует использовать режим обхода разрешений только в изолированной среде. Поместите агента в такую среду, и остальное на этой странице станет проще.

Режимы разрешений Claude Code

У Claude Code четыре режима. Выбирайте режим под задачу, а не один навсегда.

• default. Спрашивает перед правкой файлов и командами оболочки. Подходит для интерактивной работы. Не подходит для ночной.
• acceptEdits. Правит файлы в рабочей папке без вопросов. Перед командами оболочки по-прежнему спрашивает. Хороший промежуточный вариант для рефакторинга, где судья это тесты.
• plan. Читает и думает, но ничего не меняет. Используйте его, чтобы получить план и проверить его до настоящего запуска.
• bypassPermissions. Никаких вопросов. Это режим для работы без присмотра. Используйте его только на изолированной машине и только с правилами deny, описанными ниже.

Режим задаётся при запуске.

claude --permission-mode acceptEdits

Или сделайте его режимом по умолчанию для проекта в файле настроек. Этот файл можно закоммитить, чтобы вся команда работала с ним.

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Правила deny работают в любом режиме

Эту часть упускают чаще всего. Правила разрешений накладываются поверх режима, и правило deny блокирует действие даже в режиме обхода. Поэтому правила deny и есть настоящая страховка при работе без присмотра. Правила allow заранее одобряют то, на что вы и так всегда отвечаете «да». Тогда агент на этом не застревает.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push origin HEAD:*)"
    ],
    "deny": [
      "Bash(git push:*--force*)",
      "Bash(git push origin main:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)"
    ]
  }
}

Читайте список deny как политику, потому что это она и есть. Никаких force push. Никаких push в main. Никакого рекурсивного удаления. Никаких исходящих запросов, которые агент придумал сам. Никакого чтения файлов с секретами. Подстройте список под свой проект, но держите список deny на каждой машине без присмотра.

Хуки для правил, которые не выразить шаблоном

Некоторые правила зависят от контекста. Хук запускает скрипт перед вызовом инструмента и может одобрить, заблокировать или изменить его. Частый пример блокирует любую команду, где упоминается имя хоста продакшена, что бы это ни была за команда.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/block-prod.sh" }
        ]
      }
    ]
  }
}

Скрипт читает вызов инструмента из стандартного ввода и завершается с ненулевым кодом, чтобы его заблокировать. Делайте хуки маленькими и скучными. Хук, который может незаметно сломаться, хуже, чем отсутствие хука.

Git это ваша лучшая защита

Настройки внутри агента это один уровень защиты. Репозиторий это второй уровень, которому всё равно, какой агент работает.

• Защитите main. Требуйте pull request и зелёный прогон CI для слияния. Тогда случайный push ничего не сможет туда отправить.
• Одна ветка на задачу. Агент начинает со свежей ветки и пушит только её.
• Дайте агенту токен, который может пушить ветки и открывать pull request, и больше ничего. Без прав администратора. Без права удаления. Для этого подходит fine-grained токен GitHub с доступом к одному репозиторию.
• Судья это тесты. Если набор тестов падает, pull request остаётся красным, и утром вы это увидите.

Учётные данные: минимум и отдельно

Никогда не кладите личные учётные данные на машину без присмотра. Сделайте для агента отдельный аккаунт или токен с минимальными правами, которых хватает для задачи. Staging, а не продакшен. Только чтение там, где хватает чтения. Если агенту нужно войти в сервис через браузер, используйте тестовый аккаунт. Когда проект закончится, смените токен.

Запуск без интерфейса с ограничением

Для задачи из скрипта режим print выполняет один промпт и завершается. Задайте лимит ходов, чтобы запутавшийся агент не ходил по кругу всю ночь.

claude -p "Fix the failing tests in packages/api and open a PR" \
  --permission-mode acceptEdits \
  --max-turns 60

Пишите вывод в файл. Утром вы захотите прочитать, что агент сделал, а не гадать.

Те же правила для Codex

Codex CLI разделяет два вопроса. Когда он спрашивает одобрения и к чему у него есть доступ. Для задачи без присмотра внутри одного репозитория подходит такое сочетание: никогда не спрашивать и писать только внутри рабочей папки.

codex -a never -s workspace-write exec "Fix the failing tests and commit"

У Codex есть и флаг, который убирает и одобрения, и песочницу. Относитесь к нему так же, как к режиму обхода в Claude Code. Только на изолированной машине или никак.

Список «никогда»

Какой бы инструмент вы ни использовали, агент без присмотра не должен иметь возможности делать ничего из этого. Если ваша настройка разрешает хоть что-то из списка, исправьте это до первого ночного запуска.

• Пушить в защищённую ветку или делать force push куда угодно.
• Читать или отправлять секрет, который не нужен для задачи.
• Трогать данные продакшена, даже только на чтение.
• Тратить деньги. Никаких облачных консолей, страниц оплаты и рекламных кабинетов.
• Отправлять сообщения людям. Ни почту, ни чаты, ни соцсети.
• Удалять что-либо за пределами рабочего дерева.