Последнее обновление: 15 августа 2026 года. Данные сверены с документацией Anthropic, официальными уведомлениями безопасности Claude Code и первичным исследованием Wiz.

Anthropic указывает, что пользователи одобряли примерно 93% запросов Claude Code на разрешение, поэтому одних всплывающих подтверждений недостаточно для защиты от невнимательности и prompt injection. (разбор Anthropic о сдерживании действий AI-агента)

Вывод: доверенный собственный репозиторий можно запускать на основном Mac после включения песочницы и ограничения прав. Репозиторий неизвестного происхождения, установка зависимостей, открытый интернет или доступ к длительно действующим SSH- и облачным ключам требуют отдельной виртуальной машины либо выделенного облачного Mac. Безопасная схема должна одновременно ограничивать файловую систему, сетевой выход и способы обхода разрешений.

Эта статья предназначена:

  • разработчикам, которые проверяют открытые проекты и чужие Pull Request через Claude Code;
  • техническим руководителям, разрешающим агенту запускать тесты, устанавливать зависимости и обращаться к MCP-инструментам;
  • администраторам, создающим отдельные узлы для длительных задач AI Agent.

Почему запуск чужого репозитория на основном Mac начинается с ошибки доверия

Типичный опасный сценарий выглядит безобидно: разработчик клонирует внешний репозиторий, переходит в его каталог и сразу запускает claude. Но до первой осмысленной команды на границу доверия уже могут влиять настройки проекта, hooks, символические ссылки, скрипты установки и переменные окружения.

Официальное уведомление Claude Code описывало случай, когда проектная настройка могла изменить ANTHROPIC_BASE_URL, из-за чего запросы выполнялись до показа окна подтверждения доверия. Уязвимость затрагивала версии ниже 2.0.65 и была исправлена в версии 2.0.65. Это не означает, что любой современный репозиторий автоматически опасен, но показывает, почему окно «доверять этому проекту» нельзя считать первой и единственной линией защиты. (официальное уведомление безопасности Claude Code)

Риск создают не только команды, которые генерирует модель:

  • файл настроек проекта может включать hooks или изменять адрес API;
  • package.json, Makefile, pyproject.toml и другие конфигурации могут запускать установочные действия;
  • символическая ссылка может указывать за пределы рабочего каталога;
  • скрипт зависимости может читать переменные окружения или отправлять данные наружу;
  • MCP-сервер может получить инструменты и сетевые возможности, которых нет у обычного процесса;
  • текст внутри README или issue может содержать инструкции, рассчитанные на prompt injection.

Исследование Wiz от 7 июля 2026 года под названием GhostApproval отдельно рассматривало ситуацию, когда отображаемый путь в запросе на подтверждение не давал пользователю достаточно информации о реальном целевом файле, например при использовании символических ссылок. Anthropic указала, что описанный сценарий предполагает явное подтверждение действия внутри каталога с вредоносной ссылкой и находится за пределами заявленной модели угроз. Поэтому исследование следует использовать как предупреждение о границах интерфейсного подтверждения, а не как утверждение, что все версии Claude Code одинаково уязвимы. (первичное исследование Wiz о GhostApproval)

Практический критерий здесь простой: если происхождение репозитория, проектные настройки и скрипты нельзя проверить до запуска, не следует открывать его в окружении, где уже находятся рабочие ключи.

Перед первым запуском: разделите проверку кода и выполнение

Сначала репозиторий должен рассматриваться как набор файлов для чтения, а не как готовая программа. Claude Code официально рекомендует проверять команды перед подтверждением, не передавать непроверенный внешний текст напрямую агенту и использовать виртуальные машины для скриптов и обращений к внешним сервисам. (официальная документация Anthropic по безопасности Claude Code)

Чек-лист статической проверки

  • [ ] Зафиксирован точный URL репозитория и commit или tag, который предстоит проверять.
  • [ ] Просмотрены .claude/settings.json, .claude/, CLAUDE.md и все project-level инструкции.
  • [ ] Найдены hooks, особенно SessionStart, PreToolUse, PostToolUse и команды, запускаемые после установки.
  • [ ] Проверены package.json, requirements.txt, pyproject.toml, Makefile, Dockerfile, shell-скрипты и workflow-файлы.
  • [ ] Символические ссылки перечислены отдельно и проверены через readlink или аналогичный инструмент.
  • [ ] В MCP-конфигурации нет неизвестных серверов, локальных сокетов и внешних endpoint.
  • [ ] Необычные домены, IP-адреса, команды загрузки и закодированные строки вынесены на отдельную проверку.
  • [ ] Из репозитория удалены или заменены тестовые файлы, содержащие реальные токены.

Проверку лучше выполнять в режиме плана: он позволяет читать файлы и запускать команды только для исследования, не изменяя исходный код. В документации Claude Code режим plan отделён от режимов, которые принимают редактирование или автоматически одобряют действия. (документация Anthropic по разрешениям Claude Code)

Уберите секреты до того, как появится оболочка

На основном Mac перед проверкой необходимо отключить доступ к:

  • ~/.ssh, включая приватные ключи и known_hosts, если они не нужны для конкретной задачи;
  • файлам облачных учётных данных;
  • переменным production-окружения;
  • сертификатам подписи, профилям распространения и ключам CI/CD;
  • конфигурациям CLI, где сохранены долгоживущие токены;
  • каталогам с паролями, резервными копиями и рабочими SSH-сокетами.

Важно не только не передавать эти файлы через prompt. Если они доступны процессу или смонтированы в контейнер, вредоносный скрипт может попытаться прочитать их без участия модели. Документация Anthropic отдельно предупреждает не монтировать в Dev Container ~/.ssh и облачные credential-файлы, а для задач разработки использовать короткоживущие или ограниченные токены. (документация Anthropic по Dev Container)

Выберите уровень изоляции до запуска команд

Права Claude Code и системная песочница решают разные задачи. Permission system определяет, какие инструменты разрешены, а sandbox ограничивает Bash и его дочерние процессы на уровне операционной системы. На macOS для этого используется Seatbelt; ограничения распространяются на процессы, запущенные через npm, terraform, kubectl и другие команды. (документация Anthropic по sandbox и macOS Seatbelt)

Сценарий Начальная среда Что разрешать Когда остановиться
Собственный доверенный проект Основной Mac с sandbox Чтение, тесты, запись в рабочий каталог При запросе к секретам или неизвестному домену
Открытый репозиторий без установки зависимостей Основной Mac только в режиме плана Чтение, поиск, статический анализ До первого запуска скриптов
Чужой проект с npm install, pip install или сборкой Dev Container или отдельная VM Только необходимые каталоги и домены При требовании ключей хоста
Незнакомый проект с длительным агентом и открытым интернетом Выделенная VM или облачный Mac Короткоживущие учётные данные, allowlist сети После завершения и проверки очистки
Нужны физические Apple-инструменты или macOS toolchain Отдельный облачный Mac с изоляцией Минимальный набор сервисов После уничтожения или пересоздания среды

Если репозиторий доверенный, секреты удалены, а задача ограничивается тестами внутри каталога — выбирается локальная песочница. Если хотя бы один из этих пунктов не выполняется, выбирается Dev Container, VM или отдельный Mac.

Включите macOS Seatbelt и запретите тихий выход из песочницы

В Claude Code песочница запускается командой:

/sandbox

Для управляемой среды нельзя оставлять поведение по умолчанию, при котором при отсутствии зависимостей или неподдерживаемой платформе показывается предупреждение, а команды продолжают выполняться без sandbox. В конфигурации следует включить жёсткий отказ:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": [
        "~/.ssh",
        "~/.aws",
        "~/.config/gcloud"
      ],
      "denyWrite": [
        "~/.ssh",
        "~/.aws",
        "~/.config/gcloud",
        "/usr/local/bin"
      ],
      "allowWrite": [
        ".",
        "/tmp/build"
      ]
    },
    "network": {
      "allowedDomains": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org"
      ]
    }
  }
}

Названия доменов в этом примере не являются универсальным allowlist для любой команды: каждый endpoint должен быть обоснован конкретной задачей. Встроенный прокси ограничивает hostname, но не расшифровывает TLS-трафик и не инспектирует его содержимое. Поэтому разрешённый домен всё ещё может быть скомпрометированным или принимать нежелательные данные.

Параметр allowUnsandboxedCommands: false особенно важен для длительных задач. Claude Code может попытаться повторить неудачную команду вне sandbox через параметр dangerouslyDisableSandbox; при отключённом escape hatch такая попытка не превращается в незаметный выход за границу.

Важно: macOS Seatbelt ограничивает Bash и его дочерние процессы, но не превращает весь Mac в виртуальную машину. Отдельные инструменты Claude Code, MCP-серверы и действия, выполняемые вне Bash, дополнительно контролируются системой разрешений. Эти слои нельзя считать взаимозаменяемыми.

Настройте права: deny, ask и allow должны работать вместе

В Claude Code правила оцениваются в порядке deny → ask → allow; первое совпадение имеет приоритет, поэтому запрет должен формулироваться раньше широкого разрешения. Документация также подчёркивает, что sandbox и permissions дополняют друг друга: permissions не дают инструменту начинать запрещённое действие, а sandbox ограничивает результат на уровне ОС.

Для первичного анализа незнакомого проекта подходит консервативная схема:

{
  "permissions": {
    "defaultMode": "plan",
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/gcloud/**)",
      "Edit(~/.ssh/**)",
      "Edit(~/.aws/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)",
      "Bash(git push *)",
      "WebFetch(domain:*)",
      "MCP(*)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(pnpm install *)",
      "Bash(pip install *)",
      "Bash(brew install *)",
      "Bash(git fetch *)"
    ]
  }
}

Эти правила требуют адаптации: запрет MCP(*) логичен до проверки серверов, но может остановить рабочий процесс, если MCP нужен для анализа. В таком случае сначала разрешается конкретный сервер, а не весь класс инструментов.

Защищает ли sandbox SSH-ключи? Только при корректно закрытом доступе к ним. Если ~/.ssh запрещён для чтения и не смонтирован в контейнер или удалённую среду, Bash-процессы не должны получить его через песочницу. Но это не абсолютная гарантия для всей системы: ключ может быть доступен через уже запущенный SSH-agent, другой разрешённый инструмент, MCP-сервер или ошибочно добавленный путь. Для незнакомого репозитория безопаснее удалить ключи из среды и использовать отдельную краткоживущую учётную запись.

Первый запуск: Dev Container не равен полной изоляции

Dev Container полезен, когда нужно повторяемое окружение для сборки и тестов, но он не изолирует автоматически всё, что доступно контейнеру. Рабочий каталог обычно монтируется с хоста, а разрешённый сетевой выход может быть использован для отправки данных. Anthropic прямо предупреждает, что при запуске без запросов разрешения вредоносный проект способен вывести из контейнера всё, что доступно внутри него, включая учётные данные Claude Code; также не следует монтировать секреты хоста.

Может ли Dev Container полностью изолировать Claude Code? Нет. Он отделяет инструменты и процессы разработки от основной системы, но bind mount рабочего каталога, сохранённые credentials, широкая сеть, Docker socket или подключённые секреты сохраняют путь к утечке. Для доверенного кода Dev Container часто достаточен; для неизвестного проекта с долгим автономным запуском нужна VM или отдельный облачный Mac.

Минимальные меры для контейнера:

  • запускать Claude Code от непривилегированного пользователя;
  • не подключать Docker socket без отдельного обоснования;
  • не монтировать ~/.ssh, cloud credentials и production-файлы;
  • ограничить egress firewall-правилами;
  • использовать временный workspace вместо постоянного bind mount;
  • не сохранять токены между пересозданиями без необходимости;
  • запретить --dangerously-skip-permissions через управляемые настройки, если команда не может гарантировать изоляцию.

Для руководителя полезно закрепить организационные ограничения через managed settings: можно запретить bypass-режим, оставить только корпоративные permission rules и ограничить подключение MCP-серверов. (административная документация Anthropic для Claude Code)

Когда локальная песочница уже не подходит

Решение следует принимать не по удобству команды, а по размеру возможного ущерба.

  • Если репозиторий проверен, зависимости известны, интернет не нужен, а ключи удалены, остаётся локальный Mac с Seatbelt и режимом plan или обычным подтверждением.
  • Если требуется воспроизводимый toolchain, но код относительно доверенный, выбирается Dev Container с ограниченной сетью и временными токенами.
  • Если проект неизвестен, запускает установочные скрипты или должен работать часами без наблюдения, выбирается отдельная VM или облачный Mac.
  • Если нужны Xcode, симуляторы, Apple SDK, GUI-инструменты или полноценная macOS-сессия, практичнее выделенный Mac, а не контейнер.
  • Если задача включает production-доступ, подпись приложения или постоянные SSH-ключи, сначала меняется модель доступа: используются короткоживущие credentials, отдельные аккаунты и подтверждение каждой операции.

При выборе удалённой среды стоит заранее проверить не рекламное название тарифа, а реальные свойства: можно ли пересоздать окружение после задания, как удаляются диски, выдаются ли учётные данные отдельно, можно ли ограничить исходящий трафик и кто имеет доступ к журналам. Для сравнения доступных вариантов можно изучить условия аренды удалённого Mac, а регион размещения выбрать через список доступных площадок RUVCLOUD.

Здесь важен не сам факт удалённого запуска. Отдельный облачный Mac становится полезнее локального компьютера только тогда, когда его можно создавать под задачу, не хранить в нём постоянные секреты и уничтожать после завершения проверки. Если среда сохраняется месяцами с теми же ключами и широким доступом в сеть, удалённость сама по себе не уменьшает риск.

Завершите задачу проверкой побочных эффектов

Удаление изменённых файлов не отменяет сетевой запрос, публикацию токена или изменение внешнего сервиса. После выполнения незнакомого репозитория нужно проверить не только Git diff.

Чек-лист завершения

  • [ ] Выполнен git status --short, просмотрены tracked и untracked-файлы.
  • [ ] Проверены новые hooks, изменения в shell-конфигурации и задания планировщика.
  • [ ] Проверен список SSH-ключей и authorized_keys, если среда позволяла SSH.
  • [ ] Просмотрены логи сетевых запросов, DNS и обращения к необычным доменам.
  • [ ] Отозваны временные токены и API-ключи.
  • [ ] Проверены опубликованные ветки, Pull Request и артефакты CI/CD.
  • [ ] Удалены временные контейнеры, volumes и кэш с credentials.
  • [ ] Для одноразовой задачи создан новый экземпляр вместо продолжения работы в уже использованной среде.

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

Если нужен отдельный узел для длительного выполнения Claude Code, сначала следует определить границы файлов, доменов и секретов, затем проверить процедуру пересоздания. После этого можно создать заказ на удалённый Mac в RUVCLOUD под конкретную задачу, а не переносить на облачный узел весь профиль основного компьютера.

Основной Mac удобнее для доверенных проектов, но он обычно содержит постоянные SSH-ключи, облачные профили, рабочие сессии и доступ к личным файлам. Dev Container сокращает поверхность атаки, однако сохраняет риски bind mount, credentials и разрешённой сети. Поэтому для чужого репозитория с установкой зависимостей или долгим автономным заданием отдельная VM либо облачный Mac даёт более понятный взрывной радиус: среду можно ограничить, проверить и уничтожить, не затрагивая основной рабочий компьютер. Решение об аренде следует принимать только после проверки, что конкретная среда действительно поддерживает нужные ограничения, очистку и пересоздание.