Формулировка из документации Claude Code предельно прямая: плагины и marketplace — это компоненты с высоким уровнем доверия, они могут выполнять произвольный код на вашей машине с вашими правами пользователя. Anthropic не контролирует, какие MCP-серверы, файлы и программы входят в плагины, и не может гарантировать, что они работают так, как заявлено.
Это не абстрактная угроза. Плагин может принести хук, который запускается после каждой правки файла, и MCP-сервер, который стартует при старте сессии. Оба выполняются автоматически, без вашего участия и без отдельного запроса. Устанавливая плагин, вы фактически принимаете чужой код в свой рабочий процесс.
После этого урока вы будете понимать, чем именно рискуете, что смотреть до установки, чем отличаются официальный и сообщественный marketplace по уровню проверки и как организация может ограничить, откуда сотрудники ставят плагины.
Что уже умеем / что добавим
Мы научились собирать плагины, проверять их и распространять через marketplace. Теперь посмотрим с позиции того, кто ставит чужой плагин: какие компоненты работают автоматически, как оценить плагин по разделу Will install, чем помогают разрешения и песочница и как работает ограничение strictKnownMarketplaces в управляемых настройках.
Что вы узнаете в рамках статьи
- Почему плагин — компонент с высоким уровнем доверия и что он выполняет автоматически
- Что показывает карточка плагина до установки и как ей пользоваться
- Чем различаются официальный, сообщественный и произвольный marketplace
- Как ограничить список разрешённых marketplace на уровне организации
- Что делать с плагинами, которые вы поставили и перестали использовать
Ключевые термины
- Модель доверия — принцип, по которому плагин выполняется с вашими правами и ответственность за выбор источника лежит на вас.
strictKnownMarketplaces— ключ управляемых настроек, задающий белый список разрешённых marketplace.- Раздел Will install — блок карточки плагина со списком компонентов, которые он добавит.
- Context cost — оценка того, сколько токенов контекста плагин займёт на каждом ходу.
blockedMarketplaces— ключ управляемых настроек для запрета конкретных источников.
Что именно выполняет плагин
Полезно разложить компоненты плагина по степени автономности — это и есть карта рисков.
Скиллы запускаются, когда вы их вызываете или когда Claude решает, что скилл уместен. Наименее автономная часть, но и здесь стоит помнить: тело скилла — это инструкции для модели, и они могут просить сделать что угодно.
Подагенты запускаются, когда основной агент делегирует им задачу. Ограничения на них есть по умолчанию: во frontmatter подагента плагина не поддерживаются поля hooks, mcpServers и permissionMode — именно из соображений безопасности, чтобы плагин не расширял себе права через агента.
Хуки — самая автономная часть. Хук PostToolUse с матчером Write|Edit выполняет команду после каждой правки файла, без вашего участия. Это законная и полезная механика, но она же означает, что установка плагина с хуками — это согласие регулярно выполнять чужую команду.
MCP-серверы стартуют автоматически, как только плагин включён. Они получают доступ к внешним системам, к которым вы их подключили.
Каталог bin/ добавляет исполняемые файлы в PATH инструмента Bash на время работы плагина.
Практический вывод: риск определяется не количеством скиллов, а наличием хуков, MCP-серверов и каталога bin/.
Что смотреть до установки
Панель /plugin показывает карточку плагина ещё до установки, и в ней есть ровно то, что нужно для оценки.
/plugin
На вкладке Discover выберите плагин и посмотрите на три вещи:
- Will install — список того, что плагин добавит: команды, подагентов, скиллы, хуки, MCP- и LSP-серверы. Это ваш главный источник: если плагин заявлен как «форматтер», а в списке MCP-сервер и три хука, стоит разобраться зачем.
- Context cost — сколько токенов контекста плагин займёт на каждом ходу.
- Last updated — дата последнего обновления.
Оговорка: не все плагины предоставляют эти данные. Для плагинов из локальных и произвольных marketplace строк Context cost и Last updated может не быть, а вместо списка компонентов будет надпись Components will be discovered at installation. Это само по себе сигнал: вы устанавливаете вслепую.
Тот же инвентарь доступен из терминала:
claude plugin details
А раз плагин — это обычный репозиторий, самый надёжный способ проверки остаётся прежним: открыть его исходники и прочитать hooks/hooks.json и .mcp.json. Это два файла, где живёт весь автоматически выполняемый код.
Насколько отличаются источники
Три уровня, и различие между ними существенное.
claude-plugins-official — курируемый набор плагинов Anthropic. Claude Code регистрирует его автоматически при первом интерактивном запуске. Состав определяет Anthropic; процедуры подачи туда нет.
claude-community — публичный сообщественный marketplace. Плагины попадают туда после ревью: автоматическая валидация и проверка безопасности. Каждый плагин закреплён за конкретным коммитом (SHA) в каталоге. Добавляется вручную:
/plugin marketplace add anthropics/claude-plugins-community
Произвольный marketplace — любой git-репозиторий. Никакой проверки нет вообще. Ответственность полностью на вас.
Есть ещё защита от подделок: имена вроде claude-plugins-official, claude-community, anthropic-plugins зарезервированы за Anthropic, и имена-имитации (official-claude-plugins, anthropic-plugins-v2) блокируются. Проверка выполняется при каждой загрузке, а не только при добавлении; попавший под неё marketplace помечается как зарегистрированный из недоверенного источника.
Организационные ограничения
Если вы отвечаете за настройку команды, полагаться на дисциплину каждого не нужно — есть управляемые настройки.
Ключ strictKnownMarketplaces задаёт белый список. Полная блокировка, включая официальный marketplace Anthropic:
{ "strictKnownMarketplaces": [] }
Или разрешение только своих источников:
{
"strictKnownMarketplaces": [
{ "source": "github", "repo": "acme-corp/approved-plugins" },
{ "source": "github", "repo": "acme-corp/security-tools", "ref": "v2.0" }
]
}
Поддерживается и подстановка на уровне владельца: { "source": "github", "repo": "acme-corp/*" }.
Ключевая деталь: ограничения проверяются до любой сетевой или файловой операции — при добавлении marketplace и при установке, обновлении и автообновлении плагина. То есть запрещённый источник даже не будет скачан.
Важно понимать границу: strictKnownMarketplaces ограничивает, что пользователи могут добавить, но сам ничего не регистрирует. Его нужно сочетать с extraKnownMarketplaces, чтобы разрешённые каталоги подключались автоматически. Рядом существуют blockedMarketplaces, disableSideloadFlags и disableCommandPluginSources для более точечных запретов.
Гигиена: удаляйте то, чем не пользуетесь
Неиспользуемый плагин — это не нейтральный балласт. Он тратит контекст на каждом ходу, его хуки продолжают выполняться, его MCP-серверы продолжают стартовать.
Claude Code помогает это заметить: на вкладке Installed есть заголовок Not used recently — туда попадают плагины, которые вы поставили сами и не использовали как минимум две недели на протяжении не менее чем десяти сессий. У каждого плагина в карточке есть строка Last used.
Дальше два варианта:
# Отключить, сохранив установку
/plugin disable plugin-name@marketplace-name
# Удалить совсем
/plugin uninstall plugin-name@marketplace-name
И общий принцип, который стоит применять ко всем настройкам Claude Code: если что-то никогда не должно происходить, полагайтесь не на договорённости, а на механизмы принуждения. Для плагинов это правила разрешений (/permissions), песочница Bash (/sandbox) и хуки PreToolUse.
Частые ошибки
- Считать, что плагин ничего не делает, пока вы не вызвали его скилл. Хуки и MCP-серверы плагина запускаются автоматически: первые — по событиям, вторые — при включении плагина.
- Игнорировать надпись «Components will be discovered at installation». Она означает, что состав плагина заранее неизвестен: вы ставите вслепую. Для плагина из произвольного marketplace это повод открыть исходники.
- Полагаться на то, что сообщественный marketplace проверяет всё. Там есть автоматическая валидация и проверка безопасности, но это не аудит кода. Произвольный marketplace не проверяется вовсе.
- Копить неиспользуемые плагины. Они тратят контекст на каждом ходу, а их хуки продолжают выполняться. Раздел Not used recently покажет кандидатов на удаление.
Наиболее частые вопросы
- Anthropic проверяет плагины из marketplace? — Официальный курируется Anthropic. В сообщественном есть автоматическая валидация и проверка безопасности. Произвольные marketplace не проверяются никак.
- Какие компоненты плагина опаснее всего? — Хуки, MCP-серверы и каталог
bin/: они работают автоматически. Скиллы и подагенты запускаются только при обращении. - Может ли плагин расширить себе права через подагента? — Нет. Во frontmatter подагента плагина поля
hooks,mcpServersиpermissionModeне поддерживаются именно по этой причине. - Как запретить команде ставить плагины из произвольных источников? — Ключом
strictKnownMarketplacesв управляемых настройках. Пустой массив блокирует всё, список — работает как белый список. - Что смотреть, если Context cost и Will install не показаны? — Исходники плагина, в первую очередь
hooks/hooks.jsonи.mcp.json: там весь код, который будет выполняться автоматически.
Итоги
Поздравляем с завершением главы о плагинах. Вы прошли полный цикл: от идеи упаковки настроек в одну поставку до сборки, проверки, публикации и — теперь — осознанной оценки чужих плагинов. Вы знаете, какие компоненты работают автоматически, умеете читать карточку плагина до установки, различаете уровни доверия у разных marketplace и знаете, как ограничить источники на уровне организации.
Главная мысль здесь простая и стоит того, чтобы её унести: плагин выполняется с вашими правами, и решение о доверии принимаете вы. Минута на просмотр раздела Will install и файла hooks/hooks.json избавляет от целого класса неприятностей.
Дальше нас ждёт финальная глава курса — автоматизация и диагностика. Начнём с headless-режима: научимся запускать Claude Code без интерактивной сессии, встраивать его в скрипты и обрабатывать целые пачки файлов одной командой.