Claude Code Mods: плагины, меняющие поведение агента
1 октября 2026 года Anthropic представила Mods: TypeScript-функции внутри плагинов, которые отвечают на события Claude Code — переписывают промпты, перехватывают вызовы инструментов, решают за разрешения, правят UI. Моды работают с правами самого Claude Code и не изолированы. Разбираем механику, границу доверия и главное открытие недели: мод отвечает позже ваших запретов — и вне управляемых настроек его ответ побеждает.
Срез на дату публикации: тарифы и каталог меняются — пересчитайте по методике статьи на свежих данных.
Короткий ответ
Моды — это код, отвечающий позже ваших запретов: вне управляемых настроек их ответ побеждает. Несущие запреты — только туда, где мод не отвечает после вас.
Механика: события и порядок ответов
Каждый шаг Claude Code — это событие: вызов инструмента, запрос разрешения, отрисовка. Мод подписывается на события и отвечает до, после или вместо: переписать промпт до модели, заблокировать или повторить вызов, одобрить или отклонить разрешение, вычистить секреты из вывода до чтения моделью, дорисовать интерфейс. В отличие от shell-хуков, мод живёт всю сессию: хранит состояние, обновляет UI, вызывает Claude Code обратно.
Ключевое — порядок: мод отвечает после ваших правил и обычных хуков. Проверка вызова видит решение правил и хуков и возвращает своё — и именно оно действует. Событие вызова инструмента вообще пропускает ваши хуки, если мод ответил сам. Понимание порядка важнее списка событий: кто отвечает последним, тот и решает.
- мод живёт всю сессию, хранит состояние
- отвечает после правил и хуков — его ответ действует
- может пропустить ваши хуки целиком
- порядок важнее списка событий
Trust boundary: где держать несущее
Независимая проверка на версии 2.1.287 показала: мод одобряет то, что заблокировал хук и отклонило правило запрета, — везде, кроме управляемых настроек. На машинах с управляемыми настройками (команда, предприятие) первым грузится встроенный guard, удерживающий запреты поверх пользовательских модов; проектный хук вне управляемых настроек такой защиты не получает. Вывод безжалостный: правило, которое обязано держаться при любом плагине, живёт только там, где мод не отвечает после него.
Практические места: управляемые настройки для команд, контейнер без выхода для одиночек, защищённая ветка на хостинге, секреты, которых сессия не видит в принципе. Проверка плагина перед установкой — обязательный ритуал: читать репозиторий, смотреть заявленные события и вызовы, перепроверять после каждого обновления (моды приезжают обычным путём обновлений). Отключение плагина убирает и мод вместе с его панелью.
| Где запрет | Мод отвечает после? | Держится? |
|---|---|---|
| Управляемые настройки + guard | Нет, guard раньше | Да |
| Проектный хук | Да | Нет |
| Prompt-правило deny | Да (вне managed) | Нет |
| Контейнер/сеть/ветка | Мод туда не дотягивается | Да |
- несущее — только выше любого мода
- проверять репозиторий до установки и после обновлений
- отключение плагина убирает мод
- guard читается в открытую — читайте его
Практика: ставить и жить
Ставьте как пакеты: только от тех, кому доверяете код на своей машине. Начните с чтения трёх встроенных модов с тестами — они показывают канон: поддержка промптов, диф-панель, guard по умолчанию. Свои моды пишите узкими: один мод — одна задача, матчер уже задачи, состояние минимальное.
Защитный мод — это safety net, а не система разрешений: он читает текст команды, и обёртки вида подстановок, алиасов и скриптов проходят мимо. Жёсткий запрет — правилами разрешений, а не текстом. И помните: ничего из этого не ново по охвату — враждебный плагин и раньше мог всё; новое — приоритет ответов, и именно он ломает наивное «хук запретил — значит запрещено».
- ставить как пакеты: доверяешь автору — ставь
- один мод — одна задача, матчер уже
- guard-мод — сетка, запреты — правилами
- новое — приоритет, а не охват
Источники и связанные страницы
Следующий шаг
Открыть эту статью в Markdown·Поделиться в Telegram
Следующий материалNVIDIA Open Agent Safety: runtime-граница для агентов