Открыть незнакомый репозиторий - это доверие не только исходному коду. Вместе с ним приезжает исполняемая обвязка: задачи редактора, профили терминала, hooks, конфигурация MCP, скрипты подготовки worktree и lifecycle-скрипты пакетного менеджера. Всё это написано кем-то другим и запускается на вашей машине с вашими правами. Разница с исходным кодом принципиальная: код надо вызвать, чтобы он выполнился, а обвязка срабатывает сама - на открытии проекта, на открытии терминала, на установке зависимостей. Workspace Trust существует ровно для того, чтобы это решение принималось осознанно, а не по инерции нажатия.
Наивное отношение понятно: диалога доверия по умолчанию нет, и о самой границе никто не вспоминает. Механизм выключен, пока его не включат в настройках, и только после этого при открытии нового рабочего пространства появляется выбор между обычным и ограниченным режимом. Цена невнимания не видна сразу и проявляется на чужом репозитории - клонированном ради проверки, скачанном из issue, присланном подрядчиком. В ограниченном режиме ИИ-функции перестают работать, и для незнакомого репозитория документация прямо советует взять обычный текстовый редактор вместо Cursor; но именно эта граница отделяет чтение чужого кода от исполнения чужой конфигурации. Ограничение здесь не наказание, а прямое следствие того, что доверие выдаётся всему рабочему пространству сразу, а не по одному файлу.
Вторая половина безопасного старта - состояние git. Прежде чем агент начнёт менять файлы, полезно самому посмотреть, что уже изменено, на какой вы ветке, какие есть worktrees и куда указывает remote. Это дешёвая страховка: чистая исходная точка превращает любой последующий diff в осмысленную картину, а грязная - в загадку, где ваши правки перемешаны с агентскими. Remote проверяют по той же причине: ветка с привычным именем в форке и в основном репозитории ведёт себя одинаково ровно до попытки отправить изменения.
Полезно один раз увидеть этот минимум командами. Ниже - короткий git status, список remote и список worktrees. К ним возвращаются перед каждой значимой задачей, а не только при знакомстве: три строки занимают секунды и снимают целый класс последующих вопросов о том, кто и что поменял.
Доверие рабочему пространству легко спутать с режимом запуска, а это разные оси. Workspace Trust отвечает на вопрос, разрешено ли вообще исполнять конфигурацию, приехавшую вместе с репозиторием. Режим запуска отвечает на другой вопрос: что позволено делать агенту в уже открытом и уже доверенном проекте. Одно не заменяет другое. Доверенный workspace с широким режимом запуска - это два снятых ограничения подряд, и обычно снимают их в разное время и по разным поводам, не замечая, что вместе они дают агенту заметно больше, чем предполагала каждая уступка по отдельности.
Отдельно стоит понимать роль checkpoints. Cursor сохраняет локальные снимки изменённых файлов до значимых правок агента, и это удобно: неудачный шаг откатывается внутри работы, не превращаясь в спасательную операцию. Но checkpoint - это механизм отмены изменений агента, а не система истории. Git остаётся местом, где живут ветки, review и совместная работа; полагаться на снимки как на замену коммиту - значит однажды обнаружить, что откатывать уже нечего.
Из этого следует жёсткое правило про грязное дерево. Если в рабочей копии есть чужие или ваши прежние незакоммиченные изменения, агенту нельзя разрешать приборку. Правильный запрос - показать git status, отделить существовавшее до задачи и явно не трогать его: не откатывать, не форматировать, не включать в коммит. Самая обидная потеря в работе с агентами - не сломанный код, а аккуратно убранная незакоммиченная работа, которой нет ни в одной истории и которую нечем восстановить.
Когда грязное дерево не убрать, помогает отдельный checkout. Worktree даёт агенту собственную рабочую копию того же репозитория: та же история, другой каталог на диске. Ваши незакоммиченные изменения остаются там, где лежали, а агент работает в своём дереве, и пересечься они физически не могут. Плата за это честная - отдельный каталог надо подготовить, зависимости в нём поставить заново, а результат потом перенести ветками. Приём стоит того, когда задача длинная или когда одновременно идут несколько, но для короткой правки на чистом дереве это лишний шаг.
Первую управляемую правку стоит провести по короткому чек-листу: git status проверен до запуска агента, задача ограничена одним наблюдаемым поведением, diff просмотрен по файлам, а не по итоговому сообщению, запущены существующие проверки проекта, и после них git status содержит только ожидаемые изменения. Пять пунктов, каждый из которых отвечает на вопрос, который иначе задают уже после неприятности.
Типичные провалы старта предсказуемы. Подтвердить доверие незнакомому репозиторию не глядя и получить чужие hooks и MCP в своей среде. Начать правку на грязном дереве и потерять границу между своим и агентским. Принять checkpoint за коммит. И оценить результат по финальному сообщению агента вместо просмотра diff по файлам.
# Грязное дерево: не дать агенту прибрать чужое
Покажи git status и отдели изменения, существовавшие до текущей задачи.
Не откатывай, не форматируй и не включай их в commit.# Состояние до запуска агента
git status --short --branch
git remote -v
git worktree list