1. Определите успех до запуска задачи без наблюдения
Полезная автономная задача конкретнее указания «исправь репозиторий». Задайте входную ревизию, разрешённые каталоги, доступные инструменты, ожидаемый артефакт, максимальное время и условия обращения к человеку. Например, задание по документации читает переданный diff и создаёт отчёт в выходном каталоге, без сетевых инструментов и изменения исходников. Такой контракт способен оценить отдельный проверяющий компонент.
Разделяйте три результата: исполнитель запустился, Claude вернул ответ, требуемая работа прошла приёмку. Процесс может стартовать правильно, а затем отклонить инструмент. Может вернуть убедительный JSON, оставив файл неизменным. Может завершить полезную работу, пока дочерний процесс продолжает работать. Единый зелёный статус скрывает эти различия и затрудняет диагностику.
План ниже относится к контролируемому вами исполнителю и одноразовым данным. Он не доказывает поведение вашей установленной версии, учётных данных или корпоративной политики. До проверки запишите версию и действующую конфигурацию. Первой выберите безвредную обратимую нагрузку и сохраните предыдущие настройки запуска, чтобы восстановление было конкретным действием.
2. Что изменилось 30 и 31 октября
| Официальный выпуск | Существенное изменение | Следствие для приёмки |
|---|---|---|
| v2.1.314, 30 октября | Ограничение записи трёх файловых инструментов; исправлен статус сбоя запуска print. | Отдельно проверьте отказ внешней записи и неудачный старт. |
| v2.1.314 | Исправлено доверие в CI для ultrareview и remote-control. | Не переносите обещание на любой неинтерактивный вызов. |
| v2.1.316, 31 октября | Очистка команд после самостоятельного выхода; исправление внешней загрузки в restricted. | Повторите проверки жизненного цикла и файлов на целевой машине. |
Официальные метаданные GitHub датируют v2.1.314 30 октября, 01:06:26 UTC, а v2.1.316 — 31 октября, 01:01:35 UTC. В Сингапуре это соответственно 09:06:26 и 09:01:35. Во время исследования официальный интерфейс последнего выпуска всё ещё указывал v2.1.316. Это время публикации, а не доказательство обновления каждой установки.
Инженерная польза — более ясный контракт между исполнителем и агентом. Документированное исправление даёт регрессионный пример для проверки, а не свидетельство невозможности всех похожих сбоев. Явно датируйте более ранний контекст: рассмотренные далее повторы MCP и события безопасности появились в выпуске от 21 октября UTC, а не в новом ноябрьском анонсе.
3. Разделите файловые инструменты, команды и внешние службы
Есть как минимум четыре пути исполнения: встроенные файловые инструменты, команды оболочки с потомками, локальные процессы интеграций и удалённые службы. Правило рабочего каталога может управлять первым, не ограничивая Python-процесс тестов или действие базы данных через MCP. Worktree отделяет работу Git, но не создаёт границу ОС вокруг всего, что из него запущено.
Документация песочницы прямо отделяет изоляцию команд от файловых и веб-инструментов, локальных серверов MCP, хуков и вспомогательных процессов. Удалённый инструмент вообще может работать на другой машине. До настройки разрешений составьте небольшой перечень: какой процесс пишет, какую учётную запись использует и какой компонент способен его остановить.
Для задания только с отчётом убрать ненужный путь исполнения зачастую проще проверить, чем открыть его и составить множество исключений. Это архитектурный выбор, не обещание надёжности любого входа при меньшем числе инструментов. Храните перечень инструментов, разрешения и изоляцию времени выполнения отдельными полями конфигурации задания.
4. Используйте новую границу записи без выдумывания недостающей справки
Примечание к выпуску называет permissions.blockWritesOutsideWorkingDirectories и утверждает, что Write, Edit и NotebookEdit отклоняют пути вне рабочих каталогов во всех режимах разрешений. Это содержательное утверждение о названных инструментах. Оно не гарантирует ограничение произвольных команд, удалённых служб или любого способа передачи информации из сеанса.
В официальном справочнике настроек, который мы проверили, не было отдельной записи для нового ключа. Поэтому здесь нет предположенной полной конфигурации, значения по умолчанию, правила передачи в удалённые сеансы или крайних случаев дополнительных каталогов. Прежде чем полагаться на настройку, проверьте её принятие и реальный отказ в развёртываемой версии. Молча проигнорированный ключ создаёт ложную уверенность.
Отделяйте имена инструментов от синтаксиса путевых правил. Справочник разрешений говорит, что ограниченные путём правила редактирования используют Edit(path); правила Write(path) и NotebookEdit(path) не участвуют в файловых проверках. Посмотрите итоговое правило и его источник. Проверьте внутренний, соседний и специально добавленный тестовый каталог, не используя настоящие файлы домашнего каталога.
5. Проверьте изоляцию оболочки, доступность и обходные режимы
Тест оболочки должен задействовать дочерний процесс, а не только вызов Edit. Разрешённая сборка может запускать скрипты, косвенно открывающие файлы. Документация файловых правил описывает эти ограничения; выполняющийся подпроцесс ограничивает граница ОС. Встроенная песочница поддерживает macOS, Linux и WSL2. Обычная Windows не получает такую же защиту от наличия JSON-настройки.
Для поддерживаемых одноразовых исполнителей официальный пример управляемой песочницы объединяет следующие настройки. Это форма конфигурации для рассмотрения, а не установленная или выполненная нами настройка:
{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}Эти параметры обрабатывают недоступность изоляции и повторы вне песочницы. Они не охватывают каждую исключённую команду или внешний процесс. Чтение по умолчанию всё ещё достигает значительной части машины, включая учётные данные; проверяйте чтение и наследуемое окружение вместе с записью. Если требуется ограничить всю цепочку, поместите весь процесс в правильно настроенный изолированный исполнитель и проверьте монтирования и сеть.
Посмотрите конфигурацию через /sandbox. Пусть безвредную проверку выполнит инструмент агента: ручной ввод в обычном приглашении ! может проверить другой, неизолированный путь. Проверка macOS не подтверждает поведение WSL-образа с отсутствующими зависимостями.
6. Решите, что может обнаруживать неинтерактивный запуск
Режим print — интерфейс исполнения, а не автоматическая граница доверия. Обычный claude -p не показывает диалог доверия к рабочей области и может обнаружить хуки и MCP-конфигурацию проекта. Нельзя обобщать исправление CI для ultrareview и remote-control от 30 октября на этот другой путь. До запуска стороннего репозитория проверьте поставляемый им исполняемый контент.
--bare уменьшает автоматическое обнаружение расширений конфигурации. Он не создаёт изоляцию ОС; документы описывают исключения и взаимодействие источников настроек. Для Anthropic API bare использует API-реквизиты, а не вход по подписке. Поэтому способ аутентификации и оплаты должен быть явным решением развёртывания; наши примеры не отправляли запрос модели.
Справочник CLI различает --allowedTools, заранее разрешающий совпавшие вызовы, и --tools, ограничивающий доступность встроенных инструментов. Последний не удаляет MCP-инструменты. Совместно проверьте --setting-sources, явные настройки и MCP-конфигурацию. Для корпоративного принуждения смотрите управляемые настройки, не предполагая, что локальный флаг отменяет политику. Версионируйте запуск и проверенную конфигурацию одним пакетом.
7. Разделяйте перечень MCP, учётные данные и безопасность повторов
Подключение MCP даёт отдельную возможность. Перечислите серверы, транспорт, допустимые инструменты и бизнес-действия. Локальный сервер может стартовать с доступом к машине, удалённый — хранить реквизиты, которых Claude не видит. Ограничивайте доступ и задачи самого сервиса, а не считайте файловое правило агента политикой базы данных или трекера задач.
Справочник MCP описывает однократный повтор прерванного ожидающего HTTP-вызова, если инструмент объявлен читающим или идемпотентным. Более ранний v2.1.307 датирует исправление 21 октября UTC. Декларация не доказывает безопасность повторной оплаты, сообщения или создания ресурса. Реализуйте и проверьте настоящее поведение сервиса, используя идентификатор операции, когда это уместно.
Для приёмки используйте локальный имитатор с журналом. Посчитайте вызовы и конечное состояние после намеренно прерванного ответа. Успешный повтор не доказывает доставку ровно один раз. Никогда не используйте реальный клиентский процесс как тест. Не сохраняйте секреты в журнале; проверяйте истечение доступа одноразовыми реквизитами, не нарушая производственный вход.
8. Согласуйте статус выхода, JSON и артефакт
Исправление старта облегчает обнаружение ранее вводившего в заблуждение сбоя. Обёртка всё равно должна отдельно собирать код выхода, stdout, stderr, длительность и идентификатор задачи. Нулевой код — свидетельство результата процесса, не независимое подтверждение правильности изменения репозитория.
Структурированный вывод поддерживает JSON и предоставленную схему. До использования проверьте наличие structured_output: документация отмечает, что запуск может завершиться без него. Проверка схемы оценивает форму. Она не устанавливает существование указанного файла, фактический запуск теста или фиксацию заявленного бизнес-состояния.
Передайте отдельному проверяющему компоненту путь ожидаемого артефакта и детерминированные условия. Отчёт может требовать UTF-8-файл со ссылками на известные тестовые данные; изменение кода нуждается в собственных подходящих проверках. Сравните изменения с разрешённым набором файлов и отклоняйте неожиданные правки. Отличайте отказ действия от сетевого сбоя; сохраняйте объяснение агента, но не заменяйте им проверку результата.
9. Ограничьте время и проверьте очистку после отмены
Установите крайний срок исполнителя вне цикла модели. Определите, как запуск запрашивает остановку, сколько ждёт и как находит только процессы этого задания. Тайм-аут — конечное состояние задачи, не разрешение оставить работу активной навсегда. Не завершайте посторонние процессы по широкому совпадению имён.
Исправление очистки от 31 октября касается команд, оставшихся после самостоятельного выхода Claude Code на macOS и Linux. Оно не доказывает удаление всех отделившихся потомков или отмену работы, уже отправленной удалённому MCP. Для обоих случаев нужны отдельные наблюдения.
В одноразовом наборе дочерний процесс может писать периодический сигнал только внутрь тестового каталога. После отмены убедитесь, что сигнал прекратился и процесс задания закончился. Для удалённых асинхронных задач используйте имитатор и проверяйте конечное состояние. Если отмена не поддерживается, зафиксируйте ограничение и выберите приемлемые побочные эффекты. Помечайте незавершённые артефакты явным отказом, чтобы последующие задания не публиковали их как готовые.
10. Собирайте свидетельства отказа, а не всё содержимое подряд
Записывайте задачу, версию, ревизию конфигурации, фактическую рабочую область, инструменты, результат и вердикт проверяющего компонента. Так можно различить «граница сработала», «модель не пыталась» и «сборщик потерял событие». Запись отказа полезна, когда связана с попыткой операции и независимо проверенным конечным состоянием.
Справочник мониторинга Claude Code документирует claude_code.safety_event начиная с v2.1.307, но перечисляет и вызовы без этого события. Собственные поля не содержат необработанные команды и пути; общие атрибуты могут нести информацию рабочей области, а дополнительное подробное журналирование добавляет контент. Не называйте весь поток анонимным и не считайте каждый отказ представленным.
Начните с минимальных метаданных и нескольких синтетических событий. Защитите адрес сборщика и политику хранения. Подтвердите поступление записей до интерпретации отсутствия события. Эти решения инструментов CLI отличаются от аналитики стоимости API: объясняют границы исполнения, но не сверяют счёт и не доказывают все внешние эффекты.
11. Выполните матрицу приёмки на одноразовых данных
Создайте новый временный родительский каталог с workspace/, sibling/ и results/. Поместите безвредный контрольный текст в sibling и сохраните его хеш. Все цели оставьте внутри временного каталога; не подставляйте реальные секреты, домашние файлы или системы клиентов. Следующий план предложен нами и не выполнялся для статьи.
| Случай | Безвредная проверка | Обязательное наблюдение |
|---|---|---|
| Файловая граница | Запись в workspace и попытка изменить соседний контрольный файл. | Разрешённый результат появляется; хеш отклонённой цели неизменен. |
| Дочерний процесс | Небольшой тестовый скрипт пытается выполнить ту же запись. | Её блокирует нужная граница оболочки; файловый тест не заменяет этот. |
| Дополнительный каталог | Явно добавить одноразовый каталог и проверить пути. | Доступ соответствует замыслу; неизвестное поведение останавливает выпуск. |
| Нет песочницы | Исполнитель без обязательной зависимости. | Обязательная изоляция прерывает старт, а не молча отключается. |
| Старт и вывод | Синтетический сбой старта, затем известная корректная задача. | Сбой даёт ненулевой код; успех дополнительно проходит JSON и артефакты. |
| Разрыв MCP | Имитатор регистрирует читающие, идемпотентные и прочие операции. | Число вызовов и состояние объясняют повтор без реальных эффектов. |
| Тайм-аут | Отменить короткий процесс периодического сигнала. | После срока остановки нет сигнала и процесса этого задания. |
| Путь свидетельств | Известный отказ и одна разрешённая операция. | Сопоставимы записи исполнителя, доступная телеметрия и проверенное состояние. |
Проверяйте отрицательные сценарии так же серьёзно, как успешный путь. Сохраняйте хеши до и после, точные флаги запуска и источник политики. Для каждого варианта используйте новые данные. Уже расширенная рабочая область может скрыть чрезмерное разрешение дополнительных каталогов и дать ложное прохождение.
12. Выпускайте пакет конфигурации, затем расширяйте нагрузку
Объедините версию CLI, запуск, выбор модели, источники настроек, ожидания управляемой политики, перечень MCP, тайм-аут и проверяющий компонент. Назначьте ревизию и точку отката. Обновление зависимости без соответствующей конфигурации может вернуть обнаружение настроек или изменить интерпретацию сбоя обёрткой.
Начните с отчётов или столь же обратимых работ. Продвигайте пакет после прохождения обязательных примеров в каждой целевой ОС, затем наблюдайте ограниченную настоящую нагрузку. Заранее определите остановку: меняется внешний артефакт, остаётся необъяснимый процесс, повторяется неидемпотентная операция или невозможно проверить обязательную конфигурацию.
Оставшиеся неизвестные — практические условия выпуска: недостающая справка нового ключа, поведение конкретной машины, отмена удалённой работы и полнота телеметрии. Официальная заметка подтверждает изменение; ваши записанные тесты — только проверенные конфигурацию и нагрузку. Сохраняйте этот охват при публикации выводов и повторяйте нужные случаи после обновления CLI, обёртки, политики или интеграции.