Cursor permissions.json autoRun schema: allow_instructions, block_instructions, local.customTools и вложенные субагенты

Июньский релиз Cursor SDK выглядит как набор улучшений качества жизни: кастомные инструменты, авто-ревью классификатор, JSONL-хранилище для персистентности, вложенные субагенты и пакет патчей стабильности. Но поисковый спрос конкретнее: команды спрашивают, как настраивать permissions.json autorun.allow_instructions и autorun.block_instructions, как local.customTools взаимодействует с local.autoReview, и даёт ли JSONL store устойчивый audit trail. Прочитайте это снова с позиции оператора — картина меняется. Cursor SDK 0.1.6 превращает три вещи, которые команды раньше собирали вручную — интеграцию MCP, управление согласованиями и наблюдаемость запусков — в нативные примитивы SDK. Это меняет дизайн локальных fleet-агентов и вопросы, на которые должен отвечать AI gateway.

Что вышло

Пять изменений имеют наибольшее значение для операторов:

• Кастомные инструменты через встроенный MCP. local.customTools теперь позволяет передавать определения функций в Agent.create() или для каждого send(). SDK предоставляет их агенту через встроенный MCP-сервер custom-user-tools — модель вызывает ваш код по тому же пути и с теми же permission gate, что и любой другой MCP-инструмент. Кастомные инструменты также видны всем субагентам родительского агента.
• Авто-ревью с правилами на естественном языке. Headless-агенты раньше выполняли вызовы инструментов без запроса, так как человека в цикле нет. local.autoReview теперь направляет такие вызовы через классификатор. Управление классификатором осуществляется через autoRun.allow_instructions и autoRun.block_instructions в permissions.json — правила на естественном языке: «read-only проверки build-артефактов в ./dist допустимы» или «всегда останавливайся на операциях удаления для ручного подтверждения».
• JSONL и подключаемая персистентность. Метаданные агентов и запусков раньше хранились в SQLite. Теперь можно переключиться на JsonlLocalAgentStore (append-only файл для diff и commit) или реализовать публичный интерфейс LocalAgentStore — in-memory для эфемерных CI-прогонов, Postgres для production-паритета.
• Вложенные субагенты на любую глубину. Субагенты могут порождать собственных субагентов, каждый с отдельным prompt и моделью. Feature-флага нет — субагентная сессия автоматически регистрирует executor для вызова Task.
• Корреляция через requestId и патчи стабильности. Каждый send() теперь несёт requestId, сгенерированный платформой, который экспонируется в Run и RunResult и сохраняется во всех трёх хранилищах. Cloud-сессии агентов корректно стримят данные по HTTP/1.1. wait() больше не резолвится до записи терминального результата. Локальный shell использует бандленый rg — PATH не засоряется на Windows.

Есть ещё одна строчка — тихая, но важная: скрипты, по-прежнему пинящие устаревший slug composer-2, молча перенаправляются на Composer 2.5. Это vendor-managed миграция моделей, не окно deprecation, и она идёт в одном релизе с новым авто-ревью классификатором — оба работают на Composer 2.5.

Почему это важно для AI-инженерных команд

До 0.1.6 вывод Cursor local agent в production требовал ручной склейки трёх вещей: внешнего MCP-сервера для кастомных инструментов, обёртки вокруг агента для блокировки деструктивных вызовов, и либо кастомного хранилища, либо аккуратного управления SQLite в условиях multi-process оркестрации. Каждое — отдельный мини-проект с отдельной границей аудита.

Этот релиз переносит все три внутрь SDK:

• Кастомные инструменты = MCP без отдельного MCP-сервера. Раньше подключить внутренний lint-конфиг означало stdio MCP-сервер, process supervisor и запись в permissions. Теперь достаточно определения функции. MCP-слой никуда не делся — он просто встроен — а значит, те же allow-list, те же соглашения именования инструментов, та же аудитная поверхность, что у remote MCP-инструментов.
• Авто-ревью = governance, который можно читать. Правила на естественном языке в permissions.json доступны для review, diff и code-review людьми, не пишущими Cursor SDK-код. Команда безопасности или платформы может владеть block_instructions, не владея скриптом агента. Компромисс реален: звонок делает классификатор, а «классификатор разрешил» — это иная история аудита, чем «человек разрешил».
• JSONL + requestId = контракт наблюдаемости. Append-only JSONL доступен для grep, diff и отправки в log pipelines. requestId позволяет привязать один вызов send() к backend-логам, аналитике и support-тикетам во всех трёх хранилищах. Для команд, которые вручную встраивали correlation ID в прогоны агентов, это существенное обновление контракта.
• Вложенные субагенты = вопрос routing-дерева. «Ревьюер делегирует тест- райтеру, который делегирует ещё глубже» — именно этот паттерн многоуровневой оркестрации незаметно раздувает токен-затраты в coding agent fleet. Каждый уровень может выбрать свою модель, а значит, теперь есть реальное решение по routing policy на каждом уровне вложенности, а не только для топового агента.

permissions.json auto-review schema: что реально настраивать

Спрос вокруг этого релиза очень конкретный: команды спрашивают не только, добавил ли Cursor auto-review, а как настроить .cursor/permissions.json для auto-review classifier. Практическая модель такая:

• local.autoReview включает classifier-based approval для headless local agents.
• permissions.json хранит natural-language policy в autoRun.allow_instructions и autoRun.block_instructions.
• local.customTools публикует SDK-local функции через встроенный MCP-сервер custom-user-tools, поэтому эти инструменты требуют такого же policy review, как remote MCP tools.
• Любое правило, разрешающее file writes, shell execution, package-manager changes, deploy steps, credential access или network calls, должно быть узким исключением, а не широким разрешением.

Безопасный стартовый паттерн: сделать allow list скучным, а block list явным. Разрешайте read-only inspections, детерминированные test commands и записи только внутри generated-output directories. Блокируйте deletes, secrets access, production endpoints, package publishing, cloud mutations и любой tool call, чей target path нельзя разрешить до выполнения. Это не делает classifier approval равным human approval, но дает reviewers конкретную schema для diff вместо расплывчатой настройки «trust the agent».

Что это значит для router/operator

Если вы управляете AI gateway, внутренним coding agent fleet или обоими, этот SDK-релиз ставит несколько решений, которые нельзя откладывать.

1. Определите, какие кастомные инструменты остаются в SDK, а какие идут через gateway. Встроенный custom-user-tools MCP-сервер работает внутри процесса агента. Для локальных файлов это нормально. Для инструментов, обращающихся к production-системам — нет: они должны проходить через gateway, чтобы сохранить централизованную аутентификацию, rate limiting и аудит. local.customTools — для локальных возможностей; production-вызовы оставьте за remote MCP-сервером, видимым gateway.
2. Относитесь к permissions.json как к policy-as-code. autoRun.allow_instructions и autoRun.block_instructions написаны на естественном языке — их легко недооценить. Коммитьте их в тот же репозиторий, что и агент, делайте code review как на конфиг, и рассмотрите CI-проверку, которая падает при удалении block instructions. Если ваша платформенная команда управляет политиками sandbox в других местах (Claude Code availableModels, Codex sandbox profiles) — согласуйте формулировки, чтобы инженер видел одинаковое намерение вне зависимости от инструмента.
3. Зафиксируйте стратегию хранилища для каждой среды. SQLite — default; JSONL — для аудита; кастомные хранилища дают Postgres или существующий event log. Выбор зависит от того, нужна ли cross-process видимость (Postgres), дешёвые durable logs (JSONL) или быстрый локальный resume (SQLite). Решайте осознанно — не оставляйте это на усмотрение дефолтов.
4. Сделайте requestId своим correlation primitive. Пробрасывайте Run.requestId в каждую строку логов, каждое billing-событие и каждую support-эскалацию вокруг Cursor SDK-агентов. Если вы уже раздаёте gateway request ID для не-SDK трафика — решите, какой является каноническим и как они соотносятся. Сейчас самый дешёвый момент, пока скрипты и дашборды не обросли собственными корреляционными соглашениями.
5. Проведите аудит глубины вложенных субагентов. «Любая глубина» — неверный default для большинства команд. Добавьте обёртку вокруг Agent.create(), которая ограничивает максимальный уровень вложенности, отдельно атрибутирует токен-затраты по уровням и отказывается порождать субагент, для которого у вашей routing policy нет назначенной модели. Иначе самая дешёвая модель в fleet сделает больше всего работы, а самая дорогая окажется ревьюером пятого уровня.
6. Зафиксируйте переход Composer 2 → Composer 2.5. Любая инвентаризация должна отмечать SDK-клиенты, по-прежнему запрашивающие composer-2. Сегодня они получают Composer 2.5 по доброй воле vendor, а не по контракту. Обновите эти пины в клиентском коде, чтобы изменение routing-правила не стало сюрпризом.

Общий сигнал: vendor-ы coding agent тянут MCP, политики согласования и наблюдаемость внутрь SDK. Для индивидуальных разработчиков это хорошо, а для AI gateway — тихое давление: делать больше, чем просто роутить; стать местом, где каталоги инструментов, политики согласования и корреляция запусков сходятся для Cursor, Claude Code, Codex и всего, что выйдет следующим.

Что посмотреть и попробовать пользователям TheRouter

Если вы уже роутите Cursor-трафик через TheRouter, немедленный аудит прямолинеен: перечислите все определения local.customTools в репозитории, разметьте каждое как «только локально» или «должно проходить через gateway», и переведите инструменты, обращающиеся к production, за remote MCP-сервер, видимый gateway. Долгосрочная задача — воспринимать permissions.json, availableModels и allow-list gateway как одну политику, выраженную тремя способами, и пробросить requestId в billing и incident pipeline так, чтобы один SDK send() отслеживался end-to-end. По мере того как вложенные субагенты становятся нормой, ценность routing-слоя всё больше — в атрибуции затрат и управлении глубиной, а не только в выборе правильной модели для вершины дерева.