GitSpawn запускает код через Git в Claude Code

В разборе Manifold описан приём GitSpawn, при котором недоверенный репозиторий выполняет произвольную команду на машине пользователя через собственную конфигурацию Git и делает это до того, как CLI-агент покажет запрос на подтверждение, с примерами для пяти агентов, среди которых Claude Code.

Коротко

• Ключевой пример в разборе это core.fsmonitor, ускоритель для больших репозиториев: git читает настройку из .git/config репозитория и запускает указанную программу при обновлении индекса, поэтому срабатывают обычные git status и git diff.
• Клонирование, fetch и pull такую конфигурацию не переносят, поэтому атака требует, чтобы каталог попал на машину вместе с .git: архивом, через общий диск, папку синхронизации или USB-накопитель.
• Команда запускается самим агентом как дочерний процесс git, то есть вне песочницы и с правами пользователя, так что модель разрешений в Claude Code и других перечисленных агентах её не видит.

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

core.fsmonitor запускает вспомогательную программу при каждом обновлении индекса

Агенты собирают контекст о проекте сразу после открытия каталога, часть вызовов приходится на запуск, часть на начало сессии. Значительная доля этой работы идёт через git: текущая ветка, изменённые и проиндексированные файлы, пути, затронутые правкой, полный список отслеживаемых файлов, отдельный worktree для подагента.

Manifold приводит два примера из разных продуктов: git status --porcelain=2 --branch и git diff --name-only HEAD. Обе команды рядовые, и обе, как большинство команд, затрагивающих рабочее дерево, сначала заставляют git обновить индекс. Именно обновление индекса и служит точкой исполнения в этой схеме.

core.fsmonitor это настройка для больших репозиториев: вместо обхода всех файлов на диске git спрашивает вспомогательную программу, что изменилось, и запускает её во время обновления индекса. Поведение задокументировано и задумано именно таким. Настройку git читает из .git/config самого репозитория, поэтому враждебный каталог привозит команду с собой.

Конфигурация приезжает вместе с каталогом, а git clone её не переносит

Сам Git такую нагрузку по сети не переносит, и Manifold оговаривает это отдельно. Клонирование враждебного URL ничего не даёт, fetch и pull тоже: репозиторий должен оказаться на диске файлами, с уже вложенным каталогом .git. Опасен любой способ доставки готового каталога в обход клонирования.

Manifold перечисляет общий архив .zip, сетевой диск, папку синхронизации и USB-накопитель и отмечает, что так проекты и передают между собой: коллеги отдают друг другу каталог целиком, консультанты передают его клиентам. Во всех проверочных сценариях публикации репозиторий доставляли именно архивом .zip.

После этого команда из конфигурации выполняется на машине пользователя, от его имени и с его правами, как только агент обращается к git. Запуск приходится на стадию сбора контекста, то есть происходит раньше, чем пользователь подтвердит хотя бы одно действие агента.

Одна из находок вообще не связана с core.fsmonitor

В публикации разобраны пять агентов: Claude Code, Goose, Grok Build, Hermes и Qwen Code. Шаблон у них общий: обращение к git при сборе контекста идёт без очистки конфигурации репозитория, поэтому конкретный набор команд у каждого продукта существенной роли не играет.

core.fsmonitor не единственная настройка Git такого рода: по словам авторов, одна из описанных находок опирается на другую настройку того же класса и к core.fsmonitor отношения не имеет. Manifold добавляет, что тот же шаблон встречается и в агентах за пределами этого списка.

Запуск происходит вне песочницы агента: код самого продукта порождает дочерний процесс git, поэтому исполнение не проходит через запрос на подтверждение и модель разрешений его не фиксирует. Команда из конфигурации репозитория не учитывается как инструмент, требующий одобрения пользователя, ни в одном из перечисленных продуктов.

Пять названных агентов не исчерпывают список

Manifold сообщает, что тот же шаблон найден в большем числе CLI-агентов, чем перечислено в публикации, а остальные продукты в ней не названы. Открытым остаётся вопрос, начнут ли разработчики очищать конфигурацию чужого репозитория перед служебными вызовами git и как быстро это произойдёт. До тех пор практический риск зависит от того, каким путём каталог оказался на диске.