2026 Cursor Agent боится удалить файлы? Создайте изолированную песочницу на Apple Container

Симптом: Cursor Agent устанавливает зависимости, запускает команды и может стереть файлы за пределами проекта.
Самое быстрое решение: открывайте в Cursor одноразовую копию репозитория и запускайте команды через Apple Container с read-only root, единственным рабочим монтированием и отключённой сетью.

Этот подход подходит, если вам нужно изолировать Linux-инструменты, сборку, тесты и скрипты. Он не защищает каталог, который вы сами подключили на запись, и не заменяет полноценную macOS-виртуальную машину для Xcode, GUI, нативной подписи или полного Apple-процесса.

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

Последнее обновление — 29 августа 2026 года. Системные требования, CLI и параметры монтирования сверены с официальными материалами Apple Container и документацией Cursor.

Граница изоляции: Linux-контейнер против полной macOS-среды

Apple Container запускает OCI-образы Linux внутри лёгких виртуальных машин на Mac. Официальная документация требует Mac с Apple Silicon и указывает macOS 26 как поддерживаемую систему; старые версии macOS проект официально не обещает поддерживать. На дату проверки последним стабильным релизом был Apple Container 1.3.0, опубликованный 24 августа 2026 года. Перед установкой проверьте актуальный релиз, поскольку синтаксис CLI и доступные параметры могут измениться. Требования и установка Apple Container и страница стабильных релизов подтверждают эти ограничения.

Это означает следующее:

• npm, pnpm, pip, cargo, go test, Linux-компиляторы и shell-скрипты можно перенести в контейнер;
• Xcode GUI, симуляторы, Apple SDK, системные расширения и процессы, которым нужен macOS framework, останутся на хосте;
• Apple Container не превращает Linux-контейнер во «второй Mac»;
• Docker-совместимость образов не означает автоматическую совместимость всех compose-файлов и сетевых сценариев.

Главная ошибка — считать сам факт запуска контейнера достаточной защитой. Если вы подключили /Users/вы/Проекты с правом записи, процесс внутри контейнера может менять и удалять файлы в этой папке. Контейнер изолирует остальную файловую систему только настолько, насколько вы правильно настроили монтирования.

У Cursor есть собственные уровни защиты: подтверждение терминальных команд, режимы запуска, правила проекта и .cursorignore. Но официальная документация Cursor относит режимы запуска к «best-effort guardrails», то есть к мерам предосторожности, а не к жёсткой границе безопасности. Агент может менять файлы рабочего пространства, а .cursorignore не блокирует терминальные команды и не заменяет контроль доступа к файловой системе. Документация Cursor по безопасности Agent должна рассматриваться как дополнение к контейнерной изоляции.

Подготовка: копия проекта вместо оригинала

Перед установкой создайте отдельную рабочую область. Вариант зависит от того, нужно ли вам сохранить историю Git.

Временный клон

mkdir -p "$HOME/agent-workspaces"
git clone --local "$HOME/src/my-project" \
  "$HOME/agent-workspaces/my-project-agent"

--local подходит, если исходный репозиторий находится на том же диске. Для удалённого репозитория используйте обычный git clone. В Cursor открывайте только:

$HOME/agent-workspaces/my-project-agent

Не открывайте одновременно родительский каталог, содержащий исходную копию, ключи или другие проекты.

Git worktree

Если вам нужна общая история и отдельная ветка:

cd "$HOME/src/my-project"

git worktree add --detach \
  "$HOME/agent-workspaces/my-project-agent" \
  HEAD

Перед передачей каталога Agent сохраните незакоммиченные изменения:

git status --short
git diff --binary > "$HOME/agent-workspaces/before-agent.patch"

Не передавайте в контейнер:

• ~/.ssh;
• каталоги конфигурации облачных CLI;
• экспортированные секреты из связки ключей;
• production-файлы .env;
• единственный незакоммиченный вариант проекта;
• каталоги с локальными сертификатами и токенами.

Добавьте в рабочую копию несколько приманочных файлов за пределами разрешённого проекта. Например, в исходном каталоге создайте файл agent-boundary-canary.txt, но не подключайте этот каталог к контейнеру. Он поможет проверить, не ошиблись ли вы путём монтирования.

Минимальный запуск: образ, пользователь и одноразовый контейнер

Создайте рядом с копией проекта отдельный каталог инструментов:

mkdir -p "$HOME/agent-sandbox"
cd "$HOME/agent-sandbox"

Установите Apple Container из пакета со страницы релизов, затем запустите службу:

container --version
container system start
container run --rm alpine echo hello

Официальный пример использует container run --rm: контейнер запускается, выводит результат и удаляется после завершения. Параметр --rm относится к экземпляру контейнера, но не удаляет автоматически отдельные именованные тома. Синтаксис базового запуска приведён в официальном руководстве Apple Container.

Создайте Dockerfile:

FROM ubuntu:24.04

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       bash \
       ca-certificates \
       curl \
       git \
       jq \
       make \
       openssh-client \
       python3 \
       python3-pip \
       unzip \
       zip \
    && rm -rf /var/lib/apt/lists/* \
    && useradd --create-home --uid 1000 --shell /bin/bash agent \
    && mkdir -p /workspace /tmp/agent-cache \
    && chown -R agent:agent /workspace /tmp/agent-cache

USER agent
WORKDIR /workspace

CMD ["/bin/bash"]

Соберите образ:

container build \
  --platform linux/arm64 \
  --tag cursor-agent-sandbox:latest \
  .

container build читает Dockerfile, создаёт OCI-образ и использует BuildKit. В справочнике команд также описаны параметры сборки и запуска, включая платформу, лимиты CPU и памяти. Эти лимиты помогают не дать тестовому процессу занять все ресурсы, но не являются защитой от вредного кода. После обновления Apple Container выполняйте:

container run --help

Так вы увидите параметры, доступные именно в установленном стабильном релизе. Справочник команд Apple Container следует использовать как источник синтаксиса вместо старых примеров из блогов.

Скрипт запуска с ограниченной областью

Создайте sandbox-run.sh:

#!/usr/bin/env bash
set -Eeuo pipefail

if [[ $# -eq 0 ]]; then
  echo "Использование: $0 <команда> [аргументы...]" >&2
  exit 64
fi

WORKSPACE="${WORKSPACE:-$HOME/agent-workspaces/my-project-agent}"
IMAGE="${IMAGE:-cursor-agent-sandbox:latest}"

if [[ ! -d "$WORKSPACE" ]]; then
  echo "Каталог WORKSPACE не найден: $WORKSPACE" >&2
  exit 66
fi

WORKSPACE="$(cd "$WORKSPACE" && pwd -P)"

case "$WORKSPACE" in
  "$HOME"/agent-workspaces/*)
    ;;
  *)
    echo "WORKSPACE должен находиться внутри $HOME/agent-workspaces" >&2
    exit 77
    ;;
esac

exec container run \
  --rm \
  --platform linux/arm64 \
  --read-only \
  --network none \
  --user 1000:1000 \
  --cpus 2 \
  --memory 4G \
  --mount "type=bind,source=$WORKSPACE,target=/workspace" \
  --mount "type=tmpfs,target=/tmp,size=1G,mode=1777" \
  --mount "type=tmpfs,target=/run,size=64M,mode=755" \
  --workdir /workspace \
  "$IMAGE" \
  "$@"

Сделайте файл исполняемым:

chmod 700 sandbox-run.sh

Проверьте его безопасной командой:

./sandbox-run.sh bash -lc '
  id
  pwd
  find /workspace -maxdepth 2 -type f | sort | head -50
'

Что делает каждая важная строка:

• --rm удаляет экземпляр после завершения;
• --read-only монтирует корневую файловую систему контейнера только для чтения;
• --network none отключает сетевой стек контейнера;
• --user 1000:1000 не запускает задачу от root;
• --mount type=bind передаёт только выбранную копию проекта;
• type=tmpfs даёт временное место для кэша и промежуточных файлов;
• --workdir /workspace исключает случайный запуск из другого каталога;
• --cpus 2 и --memory 4G ограничивают ресурсы, но не являются полноценной защитой от вредного кода.

Важное ограничение: Dockerfile и приведённый скрипт не создают универсальную «магическую» политику безопасности. Они лишь уменьшают область воздействия. Если вам нужен другой путь проекта, сначала проверьте логику case, затем явно задайте WORKSPACE:

WORKSPACE="$HOME/agent-workspaces/other-project" \
  ./sandbox-run.sh bash -lc 'git status --short'

Не передавайте в переменной путь к домашнему каталогу целиком. Не разрешайте Agent самостоятельно менять значение WORKSPACE.

Файлы, ключи и сеть: строгий профиль против удобного профиля

Для компиляции уже подготовленного проекта используйте строгий профиль:

./sandbox-run.sh bash -lc 'make test'

В этом режиме контейнер не получает:

• домашний каталог;
• SSH-агент;
• переменную SSH_AUTH_SOCK;
• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и подобные значения;
• .env с рабочими секретами;
• доступ к произвольным хостам;
• постоянный кэш после остановки.

Если тестам требуется кэш, оставьте его в tmpfs или используйте отдельный одноразовый контейнер. Не подключайте постоянный том без необходимости: содержимое именованного тома может пережить контейнер, а последующая очистка удалит данные без возможности восстановления. Документация Apple Container по томам и временной файловой системе объясняет разницу между bind mount, named volume и tmpfs.

Для установки зависимостей используйте отдельную фазу:

1. создайте новую копию проекта;
2. запустите контейнер с сетью только на время подготовки;
3. установите зависимости во внутреннюю файловую систему образа;
4. сохраните новый образ;
5. выполняйте тесты уже с --network none.

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

Есть важная граница. --network none предотвращает сетевое подключение из контейнера, но не делает доверенными сами зависимости и не отменяет риск от подключённой на запись папки. Кроме того, сетевые режимы Apple Container развиваются. Поэтому проверяйте не только DNS, но и прямое подключение к IP в тестовом образе. Для особо чувствительных задач не используйте сетевой режим, который вы не проверили на конкретной версии.

Командные чёрные списки вроде rm, sudo или curl полезны как сигнал для ручного подтверждения, но не заменяют границы файлов и сети. Команда может быть спрятана в скрипте, архиве, интерпретаторе или цепочке оболочки.

Подключение Cursor Agent: правила против реальной границы

Откройте в Cursor только $HOME/agent-workspaces/my-project-agent. В проекте можно добавить .cursorignore:

.env
.env.*
secrets/
credentials/
*.pem
*.key

Это уменьшит вероятность попадания чувствительных файлов в индекс и контекст. Но не рассчитывайте, что файл блокирует команду вроде:

cat ../some-file

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

Добавьте в правила проекта инструкцию:

Для установки зависимостей, сборки, тестов и запуска скриптов используй только ./sandbox-run.sh.
Не запускай команды с путями вне /workspace.
Не изменяй файлы за пределами рабочего проекта.
Удаление файлов, работа с ключами, публикация артефактов и изменение конфигурации хоста требуют ручного подтверждения.

Лучше разрешать автоматический запуск только для узкого набора команд:

• ./sandbox-run.sh make test;
• ./sandbox-run.sh npm test, если Node.js уже есть в образе;
• ./sandbox-run.sh python3 -m pytest;
• ./sandbox-run.sh git diff --check;
• чтение статуса и диагностики внутри /workspace.

Ручное подтверждение оставьте для:

• rm, mv, массовой перезаписи и удаления;
• доступа к ключам, токенам и переменным окружения;
• git push, публикации пакетов и деплоя;
• изменения системных настроек;
• запуска команд с sudo;
• сетевого режима, отличного от none;
• команд, которые используют MCP, SSH или внешний сервис.

Режимы запуска Cursor помогают уменьшить число случайных подтверждений и остановить подозрительные действия, но не превращают Agent в процесс с формальной моделью безопасности. Команды с широким доступом к системе могут потребовать отдельного разрешения и выйти за пределы вашей ожидаемой цепочки. Поэтому основная граница должна находиться в Apple Container и путях монтирования, а не только в настройках Cursor.

Разрушительная проверка: доказать, а не предполагать

До реальной работы проведите пять групп проверок.

• [ ] В исходном репозитории создан контрольный файл, который не находится в agent-workspaces.
• [ ] В рабочей копии есть отдельный файл-приманка, например sandbox-canary.txt.
• [ ] Cursor открыт только на рабочей копии.
• [ ] В скрипте нет монтирования $HOME, .ssh, облачных каталогов и production-файлов.
• [ ] container --version показывает установленный проверенный релиз.
• [ ] container system start завершается без ошибки.
• [ ] Команда внутри контейнера работает от UID 1000, а не от root.
• [ ] Корень контейнера недоступен для записи.
• [ ] Сеть отключена и это проверено внутри контейнера.
• [ ] После выхода контейнер исчезает из списка.
• [ ] Оригинальный репозиторий не изменился.
• [ ] В рабочей копии видны только ожидаемые изменения.
• [ ] В логах нет секретов и токенов.

Проверка пользователя и файловой системы:

./sandbox-run.sh bash -lc '
  id
  touch /tmp/write-test
  printf "root=%s\n" "$(touch /root/write-test 2>&1 || true)"
  printf "workspace=%s\n" "$(touch /workspace/agent-write-test 2>&1 || true)"
'

Файл в /workspace должен создаваться, потому что это намеренно подключённая на запись копия. Запись в /root должна завершиться ошибкой из-за read-only root или отсутствия прав.

Проверка сети:

./sandbox-run.sh bash -lc '
  command -v ip >/dev/null && ip addr || true
  command -v getent >/dev/null && getent hosts example.com || true
'

Не делайте вывод только по ошибке DNS. Для сетевой изоляции проверяйте интерфейсы, маршруты и прямое соединение в тестовом образе. Если результат зависит от версии Apple Container, зафиксируйте его в журнале и не используйте такой профиль для чувствительных задач до повторной проверки.

Проверка удаления:

./sandbox-run.sh bash -lc '
  rm -f /workspace/sandbox-canary.txt
'

После команды убедитесь, что удалился только файл в одноразовой копии:

test ! -e "$HOME/agent-workspaces/my-project-agent/sandbox-canary.txt"
test -e "$HOME/src/my-project/agent-boundary-canary.txt"
git -C "$HOME/src/my-project" status --short

Если оригинал изменился, остановитесь. Нельзя считать конфигурацию безопасной, пока не найдено неправильное монтирование или запуск Cursor из родительского каталога.

Отдельно проверьте очистку:

container list
container volume list

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

Локальный Mac против отдельной изолированной среды

Локальная схема хороша, когда вы один работаете на Apple Silicon Mac, проект можно запускать в Linux и вам нужен быстрый одноразовый цикл «изменить — собрать — проверить». Она сохраняет локальный редактор и не требует передавать исходники в удалённую систему.

Но у неё есть реальные ограничения:

• вы всё равно управляете чувствительной машиной и можете ошибиться в пути монтирования;
• для команды трудно одинаково развернуть версии образов, правила и политику ключей;
• Xcode и macOS-специфичные этапы остаются вне Linux-контейнера;
• совместный доступ и автоматическое восстановление требуют дополнительной инфраструктуры.

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

Для редких тестов локальный Apple Container обычно проще. Для длительных тяжёлых задач, общей команды, физического доступа к Mac-интерфейсам или постоянного Xcode-пайплайна лучше не пытаться заставить Linux-песочницу выполнять чужую работу. В таком случае аренда отдельного Mac у MacHTML даёт более чистую границу: личный хост не является одновременно редактором, хранилищем ключей и исполнителем непроверенных команд. При этом для постоянной интенсивной нагрузки выгоднее оценить собственный Mac или выделенную инфраструктуру — аренда нужна прежде всего там, где важны временная мощность, изоляция и быстрый сброс среды.

Перед рабочим использованием повторяйте разрушительный тест после каждого обновления Apple Container, изменения образа, прав Cursor или структуры скрипта. Без этой проверки «песочница» остаётся только названием.