Claude Code 2.1.268: исправления правил deny и MCP

Claude Code 2.1.268 выпустили 10 сентября 2026 года, а 2.1.269 — на следующий день. Установить обновление стоит без промедления: в двух ситуациях правила deny, призванные скрывать от агента .env и служебные каталоги, не применялись без каких-либо сообщений. Также команда /mcp могла напечатать секреты из конфигурационных файлов.

Далее приведены сведения из официального журнала изменений Anthropic и документации в состоянии на 17 сентября 2026 года. На эту дату актуальной была версия 2.1.274. Описание ошибок основано на этих записях; обходы для уязвимых версий здесь не проверялись.

Дополнительные рекомендации по Ailoot доступны в документации.

Что исправили в Claude Code 2.1.268 и 2.1.269?#

Для настроек разрешений существенны четыре исправления:

1. Запреты не учитывали символьные ссылки. Правила deny и ask для каталогов-ссылок (/etc, /tmp, /var в macOS и /bin в Linux) не срабатывали, когда обращение шло по физическому пути. Bash-команды тоже могли игнорировать deny, заданный для пути через ссылку.
2. env -C и eval могли обходить запрет чтения или изменения. Если в одной командной строке встречалась конструкция, которую проверка разрешений не способна разобрать, deny для Read или Edit мог остаться без действия.
3. Правило с «!» выходило за пределы своего файла. Правило deny или ask, начинавшееся с !, влияло на настройки из других источников. Теперь оно ограничено файлом, где задано; одиночный символ ! не учитывается.
4. tee записывал файлы в обход правил. Для файла, создаваемого Bash-командой tee, не проверялись deny-правила Edit() и разрешённость пути записи. Разрешение Bash(tee:*) также больше не даёт права записывать за пределами рабочих каталогов.

В этих выпусках исправили и две другие неполадки, связанные с раскрытием данных. WebFetch теперь прекращает запрос с ошибкой через 300 секунд, если сервер сохраняет соединение открытым и не завершает ответ; длительность можно задать переменной CLAUDE_CODE_WEBFETCH_DEADLINE_MS. Ещё устранена постоянно высокая загрузка процессора во время длительных простоев.

Как работают запреты в Claude Code#

В Claude Code предусмотрены три набора правил: deny (операция всегда запрещена), ask (перед операцией запрашивается подтверждение) и allow (операция разрешена без подтверждения). Проверка выполняется именно в таком порядке. Если подходит deny, соответствующий allow его не отменит: разрешение не может служить исключением из запрета.

Правила задаются в трёх расположениях: пользовательские — в ~/.claude/settings.json, проектные — в .claude/settings.json в репозитории, локальные — в .claude/settings.local.json. Ниже пример, запрещающий читать файл с ключами:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Команда /permissions в активной сессии показывает все применяемые правила и источник каждого из них. Если чтение заблокировано, сообщение об отказе указывает соответствующее правило — это поможет провести проверку далее.

Какие сбои затронули пути и область действия правил#

Неполадки касались проверки путей и команд, а также границ применения настроек из разных файлов.

Первый случай: символьные ссылки. В macOS каталоги /etc, /tmp и /var указывают на реальные каталоги внутри /private; в Linux аналогичную роль обычно выполняет ссылка /bin. Если deny задан для одного варианта пути, а агент обращается к тому же месту под другим именем — например, по физическому пути, — правило могло не сработать. Bash-команды тоже могли обходить deny, заданный для пути через ссылку. В версии 2.1.268 устранены оба сбоя: теперь правило применяется при любом из вариантов написания пути.

Второй случай: env -C или eval в командной строке. Чтобы определить, к каким файлам обращается команда, система анализирует её текст. Конструкции вроде env -C и eval она разобрать не могла. Из-за ошибки deny для Read или Edit мог не примениться, если такая конструкция присутствовала в строке. Команда в итоге обходила ограничение на чтение или изменение закрытого файла.

Третий случай: правило с «!» за пределами заданного источника. Такое правило должно действовать лишь в том файле настроек, где его указали. До версии 2.1.269 оно влияло также на правила из других источников. Теперь область действия ограничена исходным файлом, а одинокий ! игнорируется.

Четвёртый случай: запись с помощью tee. Bash-команда tee умеет сохранять данные в файл, но раньше проверки пути записи и deny-правила Edit() не охватывали этот файл. Разрешение Bash(tee:*) при этом допускало запись вне рабочей области. В версии 2.1.269 запись через tee стала проходить обе проверки: запрет для файла применяется, а Bash(tee:*) разрешает запись только в рабочих каталогах.

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

Почему команда /mcp могла раскрыть ключи?#

Ключи MCP-серверов обычно хранят в переменных окружения и вставляют в конфигурацию через ${VAR}. Такой способ позволяет хранить конфигурационный файл в репозитории без открытого секрета. Однако команды просмотра (/mcp, /plugin, claude mcp list, claude mcp get) и ошибки входа показывали конфигурацию после подстановки значений. В результате на экране мог оказаться ключ целиком.

Также исправили вывод ошибок плагинов и маркетплейсов: в них могли попасть токен или пароль, содержащиеся в git-ссылке источника.

Если на прежней версии результат /mcp или claude mcp list оказался в трансляции, снимке экрана, сообщении коллеге либо в журнале, отправленном за пределы устройства, в том числе автоматически, считайте ключи MCP-конфигураций раскрытыми и замените их. Если данные не покидали ваш компьютер, достаточно установить обновление. Дополнительный материал о MCP-серверах и готовых конфигурациях: MCP-серверы Claude Code.

Прочие изменения в этих версиях#

WebFetch и опубликованные артефакты. Ранее общее правило WebFetch в списках deny или ask также распространялось на чтение и изменение опубликованных артефактов. Начиная с 2.1.268 оно на эти действия не влияет. Чтобы ограничить артефакты, задайте отдельное правило Artifact или ограничение по домену, например WebFetch(domain:claude.ai). Если общий запрет WebFetch служил защитой от чтения артефактов, проверьте настройки: прежнее правило теперь их не блокирует.

В WebFetch добавлен таймаут. Если сервер оставляет соединение открытым и не завершает ответ, запрос теперь завершается ошибкой через 300 секунд. Ранее ожидание могло продолжаться бесконечно. Параметр задаётся через CLAUDE_CODE_WEBFETCH_DEADLINE_MS; значение 0 отключает таймаут.

Исправлена высокая загрузка процессора в простаивающих сессиях. В продолжительных сеансах без активности фоновый цикл Claude Code мог постоянно нагружать процессор. В версии 2.1.268 эту проблему устранили. Она могла затрагивать пользователей, оставляющих сессии открытыми на целый день.

Установите актуальную версию. В версии 2.1.269 появилась отдельная неполадка: после длительной работы сессии команды Bash с git, предназначенные только для чтения данных, начинали запрашивать разрешение. Исправление вошло в 2.1.270. Поэтому обновитесь до наиболее свежей версии; на 17 сентября 2026 года это была 2.1.274. Не оставайтесь на 2.1.268 или 2.1.269.

Как обновить программу и проверить правила?#

1. Определите установленную версию. Запустите в терминале claude --version. Исправления описанных сбоев появились в версиях 2.1.268 и 2.1.269. В версиях ниже 2.1.268 их ещё нет, хотя риск конкретного сбоя зависит от используемых путей, команд и правил.
2. Установите обновление. Пошаговые действия и разбор проблем описаны в руководстве обновление Claude Code до последней версии. Выбирайте самый новый выпуск, а не только версию 2.1.268.
3. Проверьте блокировку на тестовом файле. Не используйте для проверки настоящий .env: если ограничение даст сбой, агенту станут видны реальные ключи. Создайте тестовый файл, например secret-test.txt, с произвольным содержимым, например «это проверка». В .claude/settings.json проекта внесите правило "Read(./secret-test.txt)" в список deny, перезапустите сессию и попросите: «прочитай файл secret-test.txt и скажи, что внутри». Ожидаемый результат — отказ с названием вашего правила. Если агент прочитал файл, в этом тесте блокировка не сработала. Сначала проверьте синтаксис по примеру выше и откройте /permissions, чтобы увидеть загруженные правила и их источники. Сам тест не устанавливает причину сбоя. Отказ подтверждает действие ограничения для этого файла; остальные правила нужно проверять отдельно, каждое своим тестом.
4. При необходимости проверьте символьные ссылки. Если на macOS в правилах используются /tmp, /etc или /var, а в Linux — /bin, после обновления повторите для них проверку.
5. Просмотрите правила с «!». Если они есть, убедитесь, что каждое размещено в том файле, областью действия которого должно ограничиваться.

Если ограничение срабатывает, но Claude Code не показывает нужные файлы, смотрите отдельный разбор: почему Claude Code не видит файлы проекта.

Если пока нельзя обновиться#

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

• указывайте deny для обоих вариантов пути — символьной ссылки и физического расположения (в macOS физические пути находятся внутри /private);
• не объединяйте много команд в одну строку и не используйте env -C или eval в командах, которые просите выполнить;
• не передавайте другим результат /mcp, /plugin, claude mcp list или claude mcp get; замените ключи MCP-конфигураций, если они могли стать известны посторонним;
• помните, что tee обходит deny для Edit: если Bash разрешён, не считайте файлы защищёнными этим правилом.

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

Вкратце#

В Claude Code 2.1.268 и 2.1.269 устранены четыре ошибки разрешений: обработка символьных ссылок, командных строк с env -C и eval, правил с «!» вне исходного файла и записи через tee. Также исправили раскрытие секретов в выводе /mcp и токенов в ошибках плагинов. Проверьте версию, обновитесь до последней и испытайте правило на тестовом файле, описанном выше. Отказ с названием правила подтверждает, что оно сработало в этом испытании. Одного наличия правила в настройках для проверки недостаточно.

Для дальнейшей работы с моделями можно перейти в Ailoot.