Как MCP-клиенты спрашивают, прежде чем ИИ изменит данные: 2026

Каждый MCP-клиент, который что-то значит в 2026 году, спрашивает, прежде чем ассистент запустит инструмент, который что-то меняет. Эта часть ответа скучная и успокаивающая. Полезная часть — что происходит после первого запроса, потому что сорок раз в день жать «Allow» долго никто не станет: каждый клиент предлагает способ перестать спрашивать, и насколько узок этот способ, у клиентов отличается очень сильно.

Коротко: Claude Code, Zed, Cursor и Devin Desktop позволяют заранее одобрять отдельные MCP-инструменты по имени. Codex — движок настольного приложения ChatGPT — вместо этого может решать по меткам самого сервера: спрашивать обо всём, что не помечено как read-only. VS Code делает и то и другое на уровне диалога и добавляет переключатели для всего рабочего пространства. Ни одна из этих схем не ошибочна, но ломаются они по-разному, и какая поломка важна именно вам, зависит от того, кто написал сервер.

Это сравнение дополняет наш обзор того, какие MCP-клиенты умеют запускать локальный сервер. Тот отвечает на вопрос «запустится ли», этот — на вопрос «что будет, когда ассистент решит что-то изменить». Всё ниже сверено с документацией каждого производителя 29 сентября 2026 года.

Коротко

Клиент По умолчанию для MCP-инструментов Самое узкое постоянное разрешение Решает по аннотациям?
Claude Code Спрашивает (режим Manual) На инструмент: mcp__server__tool в allow, ask или deny Не задокументировано
Коннекторы Claude Desktop Спрашивает На инструмент или категорию: Always allow, Needs approval, Blocked Делит инструменты на read-only и write/delete
Codex CLI, IDE, настольный ChatGPT Зависит от режима На сервер, с переопределением на инструмент Да: режим writes, деструктивные подсказки
ChatGPT в браузере (режим разработчика) Спрашивает перед записью На инструмент, в пределах одного разговора Да: readOnlyHint
Cursor Спрашивает Allowlist вида server:tool Не задокументировано
VS Code Спрашивает (Manual permissions) На инструмент или сервер; на сессию, рабочее пространство или навсегда Не задокументировано
Zed Спрашивает (confirm) Правило mcp:server:tool Не задокументировано
Devin Desktop Спрашивает перед любым MCP-инструментом На инструмент или весь сервер; на сессию или навсегда Не задокументировано

Основной смысл несут две колонки. «Самое узкое постоянное разрешение» говорит, можно ли доверять search, не доверяя share. «Решает по аннотациям» говорит, делает ли клиент это разделение за вас — по меткам, которые сервер написал сам о себе.

Насколько узко каждый MCP-клиент позволяет заранее одобрить инструмент
По умолчанию спрашивают все; разница в том, насколько узко можно отключить вопрос.

Codex и настольное приложение ChatGPT: четыре режима и метка

У Codex самая явная схема, и поскольку настольное приложение ChatGPT, Codex CLI и расширение для IDE используют один файл конфигурации, она покрывает все три. Каждый MCP-сервер получает default_tools_approval_mode, а любой инструмент может переопределить его через tools.<tool>.approval_mode. Задокументированы значения auto, prompt, writes и approve.

Интересен writes. По словам OpenAI, он «спрашивает про инструменты, не помеченные как read-only». Поиск выполняется молча, всё остальное останавливается и спрашивает, а инструмент вообще без аннотации считается записью — безопасное поведение по умолчанию, когда сервер ничего о себе не сообщает. Поверх режимов документация Codex об одобрениях говорит, что деструктивные вызовы MCP-инструментов всегда требуют одобрения, если инструмент объявляет деструктивную аннотацию, — кроме случая, когда он объявляет и аннотацию чтения.

Одно изменение, о котором стоит знать владельцам старых конфигов: Codex больше не поддерживает approval_policy = "untrusted", и эта снятая настройка может помешать клиенту запуститься. Доверие к проекту теперь задаётся через его trust_level.

ChatGPT в браузере работает по тому же принципу. В режиме разработчика, доступном на аккаунтах Pro, Plus, Business, Enterprise и Education, «действия записи по умолчанию требуют подтверждения»; ChatGPT учитывает readOnlyHint и считает записью любой инструмент без неё. Выбор можно запомнить для инструмента до конца разговора — и не дольше.

Claude Code и Claude Desktop: правила, которые вы пишете по имени

Claude Code не читает аннотации, чтобы решить. Он использует правила разрешений в трёх списках — allow, ask и deny, — которые проверяются в фиксированном порядке: сначала deny, потом ask, потом allow. MCP-инструменты называются mcp__<server>__<tool>, поэтому mcp__notes__search разрешает один инструмент, mcp__notes__get_* — семейство, а mcp__notes или mcp__notes__* покрывает весь сервер. Режим по умолчанию теперь называется Manual; к более свободным относятся acceptEdits, auto, где действия вместо вас проверяет классификатор, и bypassPermissions.

Две детали склоняют чашу в сторону безопасности. Серверы из закоммиченного в проект .mcp.json вообще не подключаются без вашего одобрения. А автор сервера может пометить инструмент через _meta["anthropic/requiresUserInteraction"], и тогда Claude Code показывает запрос при каждом вызове — даже в acceptEdits, auto и bypassPermissions.

Настройки коннекторов Claude Desktop, в разделе Customize → Connectors, группируют инструменты сервера по категориям — например, read-only и write/delete, — и каждой категории или отдельному инструменту можно задать Always allow, Needs approval или Blocked.

Cursor, VS Code, Zed и Devin Desktop: редакторы

Cursor говорит прямо: «По умолчанию Cursor запрашивает одобрение перед использованием MCP-инструментов». MCP подчиняется тем же Run Modes, что и команды терминала. В Auto-review вызовы из allowlist выполняются сразу, а всё остальное проходит через модель-классификатор; Run Everything выполняет любой вызов инструмента без вопросов. Allowlist принимает записи server:tool с подстановочными знаками. Одна ловушка: пустой список инструментов у сервера в allowlist разрешает все инструменты этого сервера.

VS Code называет свой уровень по умолчанию Manual permissions: всё, что не одобрено автоматически, требует подтверждения. Диалог позволяет одобрить один вызов или выдать одобрение на сессию, рабочее пространство или все будущие вызовы, а одобрения по инструментам можно задать для каждого MCP-сервера. Allow all убирает запросы полностью, а Assisted permissions, где каждый вызов оценивает модель, помечен как экспериментальный. Одно исключение заслуживает внимания: MCP-серверы, которые поставляются внутри плагина агента, «получают неявное доверие при установке плагина» и пропускают отдельный запрос доверия при запуске. Установка плагина — это и есть решение о доверии.

Zed — самая читаемая система правил. agent.tool_permissions.default равен confirm, пока вы его не поменяете; альтернативы — allow и deny. Правила называют MCP-инструменты как mcp:<server>:<tool_name> и могут всегда разрешать, всегда спрашивать или всегда запрещать, причём запрет приоритетнее. Сам запрос предлагает «Allow once», «Deny once» и «Always for» для инструмента; для MCP-инструментов доступен только вариант на уровне инструмента.

Devin Desktop, бывший Windsurf, вместе с названием сменил и модель. Его агент Devin Local «заменяет уровни автовыполнения более детальной системой разрешений» и по умолчанию спрашивает перед вызовом любого MCP-инструмента. Из запроса можно разрешить один инструмент или все инструменты этого сервера — на сессию или навсегда, — а правила Deny важнее всего остального. Администраторы Enterprise могут заранее одобрить конкретные серверы или инструменты для всей организации.

Что аннотации могут и чего не могут

Спецификация MCP даёт серверам словарь для описания своих инструментов: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. И она же говорит клиентам, насколько этому верить: клиенты «ОБЯЗАНЫ считать аннотации инструментов недоверенными, если они не получены от доверенных серверов». А ещё требует, чтобы в цепочке был человек, способный отклонить любой вызов инструмента.

Это расставляет две схемы выше по местам. Клиент, который решает по аннотациям, как режим writes в Codex, удобен с сервером, которому вы доверяете: одна строка настройки — и о каждом новом пишущем инструменте, который добавит сервер, будут спрашивать автоматически. С сервером, которому вы не доверяете, он ровно настолько безопасен, насколько честен сервер. Инструмент, который меняет данные и называет себя read-only, выполнится без запроса.

Клиент, который заставляет называть инструменты, как Claude Code или Zed, ломается с другой стороны. Ему всё равно, что утверждает сервер, но новый пишущий инструмент, добавленный в обновлении, окажется покрыт, только если ваше правило было достаточно широким, чтобы его захватить, — или достаточно узким, чтобы его пропустить и вернуться к вопросу. Правила по именам надёжнее всего писать как «разрешить эти чтения», а не «разрешить этот сервер».

Три слоя одобрения в MCP: подсказки сервера, политика клиента и ваш клик
Аннотации подсказывают, о чём спрашивать; они не заменяют сам вопрос.

Разумная настройка для сервера, который читает и пишет

Какой бы ни был клиент, четыре привычки закрывают большую часть риска:

  1. Разрешайте чтение по имени, а не весь сервер. Поиск и чтение расшифровок — то, чем ассистент занят весь день; там запрос стоит дороже всего и защищает меньше всего.
  2. Оставляйте запрос на всём, что публикует или заменяет. Публикация для других людей и перезапись текста — два вида изменений, которые не отменить, просто вернув значение назад.
  3. Полагайтесь на аннотации только для серверов, которым доверяете. Для сервера из реестра, которым вы ни разу не пользовались, называйте его инструменты в правилах.
  4. Дайте клиенту, которому доверяете меньше, экземпляр только для чтения. Если сервер поддерживает режим только для чтения, один клиент можно ограничить чтением, а другому оставить полный доступ.

Тревожные признаки: запись в allowlist Cursor для сервера с пустым списком инструментов, плагин VS Code, который никто в команде не проверял, и «Always allow», нажатое на инструменте, чьё имя вы не прочитали.

Четыре привычки при одобрении MCP-инструментов, которые меняют данные
Заранее одобряйте то, что читает, и оставляйте запрос на том, что публикует или заменяет.

Как это выглядит в Speak-Y

MCP-сервер Speak-Y написан под оба типа клиентов. Читающие инструменты — поиск записей, чтение расшифровок, саммари и списков задач, перечень тегов и каналов — несут readOnlyHint и читают библиотеку прямо с вашей машины. Инструменты, которые что-то меняют, — теги, названия, имена спикеров, повторная расшифровка, публикация в канал команды — объявлены как изменяющие данные и проходят через запущенное приложение Speak-Y, где каждый вызов записывается в журнал и где их можно отключить.

Два из них помечены destructiveHint намеренно: retranscribe — потому что заменяет текущий текст записи вместе с ручными правками, и share_to_channel — потому что коллеги могут прочитать запись раньше, чем вы её уберёте. В режиме writes в Codex эти запросы появляются без всякой настройки; в Claude Code или Zed разрешите читающие инструменты по имени, а остальные оставьте на ask.

Если нужно, чтобы клиент мог только читать, запускайте сервер с --read-only в конфигурации этого клиента: изменяющие инструменты ему вообще не публикуются, так что случайно одобрить нечего. Подключение — один клик из раздела Настройки → Интеграции, а MCP-сервер бесплатен на любом тарифе, включая Free.

Раздел Speak-Y Настройки → Интеграции с подключёнными MCP-клиентами
Чтение помечено readOnlyHint и идёт локально; изменения проходят через приложение, пишутся в журнал и отключаются.

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

FAQ

Спрашивают ли MCP-клиенты разрешение, прежде чем запустить инструмент, который меняет данные?

Все крупные клиенты по умолчанию спрашивают. Claude Code, Cursor, VS Code, Zed и Devin Desktop показывают запрос перед вызовом MCP-инструмента, пока вы не одобрите его заранее, а режим разработчика в ChatGPT требует подтверждения для каждого инструмента, не помеченного как read-only. Различается другое: насколько узко можно выдать одобрение потом — на инструмент, на сервер, на сессию или навсегда. Проверено 29 сентября 2026 года.

Какие MCP-клиенты решают, когда спрашивать, по аннотации readOnlyHint?

Явно так делают Codex и ChatGPT. Режим одобрения writes в Codex спрашивает про инструменты, не помеченные как read-only, и всегда спрашивает перед инструментом, который объявляет себя деструктивным, а режим разработчика в ChatGPT считает записью любой инструмент без readOnlyHint. В документации Claude Code, Cursor, VS Code и Zed аннотации не упоминаются как основание для одобрения: правила вы пишете сами, по имени инструмента.

Можно ли разрешить читающие инструменты автоматически, но получать запрос перед записью?

Да, в любом клиенте из этого сравнения, но механизм разный. В Claude Code, Zed, Cursor и Devin Desktop читающие инструменты разрешаются по имени, например mcp__server__search в Claude Code или mcp:server:search в Zed. В Codex режим writes делает это одной строкой, полагаясь на то, что сервер честно пометил свои читающие инструменты.

Являются ли аннотации вроде readOnlyHint гарантией безопасности?

Нет. Спецификация MCP говорит, что клиенты должны считать аннотации инструментов недоверенными, если только они не пришли от доверенного сервера. Сервер, пометивший пишущий инструмент как read-only, обходит любую клиентскую политику, построенную на этой подсказке. Относитесь к аннотациям как к удобству для серверов, которым уже доверяете, а для остальных называйте инструменты в правилах явно.

Как безопаснее всего подключить сервер с заметками встреч к ИИ-ассистенту?

Заранее одобрите только читающие инструменты, оставьте запрос на всё, что меняет данные, а клиентам, которым доверяете меньше, дайте экземпляр только для чтения. В Speak-Y запуск сервера с --read-only в конфигурации одного клиента полностью убирает из этого клиента изменяющие инструменты, а другой клиент сохраняет полный доступ со своими запросами.