# Claude Code 2.1.268: исправления правил deny и MCP
> В версиях Claude Code 2.1.268–2.1.269 исправили четыре сбоя в работе разрешений и утечку секретов через /mcp. Узнайте, кого затрагивали ошибки, как обновить программу и проверить правила доступа.
Source: https://ailoot.ai/blog/ru/claude-code-2-1-268-chto-ispravleno/
Canonical: https://ailoot.ai/blog/ru/claude-code-2-1-268-chto-ispravleno/
Language: ru
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-040
Revision: sha256-96771a60a3012fd2b845feeab0d74236e2f7b50a896a24cf3fd9bf4a71b56f64
Claude Code 2.1.268 выпустили 10 сентября 2026 года, а 2.1.269 — на следующий день. Установить обновление стоит без промедления: в двух ситуациях правила deny, призванные скрывать от агента `.env` и служебные каталоги, не применялись без каких-либо сообщений. Также команда `/mcp` могла напечатать секреты из конфигурационных файлов.
Далее приведены сведения из официального журнала изменений Anthropic и документации в состоянии на 17 сентября 2026 года. На эту дату актуальной была версия 2.1.274. Описание ошибок основано на этих записях; обходы для уязвимых версий здесь не проверялись.
Дополнительные рекомендации по Ailoot доступны в [документации](https://ailoot.ai/docs/).
## Что исправили в Claude Code 2.1.268 и 2.1.269?
Кратко
Устранены четыре сбоя в проверках доступа. Правила deny и ask обходились, если путь проходил через символьную ссылку; deny для Read или Edit мог пропускаться в командной строке с `env -C` либо `eval`. Правило с «!» распространялось за пределы настроечного файла, а команда `tee` записывала файлы, обходя deny для Edit. Кроме того, `/mcp` и `claude mcp list` могли раскрывать значения секретов из конфигураций, а ошибки плагинов — токены в git-ссылках.
Для настроек разрешений существенны четыре исправления:
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
Кратко
Настройки находятся в блоке `permissions` файла `settings.json`: deny блокирует операцию, ask просит подтверждение, allow разрешает её без подтверждения. Правила проверяются в порядке deny, ask, allow. Запись имеет вид `Инструмент` или `Инструмент(уточнение)`, например `Read(./.env)`.
В Claude Code предусмотрены три набора правил: **deny** (операция всегда запрещена), **ask** (перед операцией запрашивается подтверждение) и **allow** (операция разрешена без подтверждения). Проверка выполняется именно в таком порядке. Если подходит deny, соответствующий allow его не отменит: разрешение не может служить исключением из запрета.
Правила задаются в трёх расположениях: пользовательские — в `~/.claude/settings.json`, проектные — в `.claude/settings.json` в репозитории, локальные — в `.claude/settings.local.json`. Ниже пример, запрещающий читать файл с ключами:
```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`, а также ошибки авторизации MCP могли отображать уже подставленное значение — сам секрет. В версии 2.1.268 этот вывод очищен.
Ключи MCP-серверов обычно хранят в переменных окружения и вставляют в конфигурацию через `${VAR}`. Такой способ позволяет хранить конфигурационный файл в репозитории без открытого секрета. Однако команды просмотра (`/mcp`, `/plugin`, `claude mcp list`, `claude mcp get`) и ошибки входа показывали конфигурацию после подстановки значений. В результате на экране мог оказаться ключ целиком.
Также исправили вывод ошибок плагинов и маркетплейсов: в них могли попасть токен или пароль, содержащиеся в git-ссылке источника.
Если на прежней версии результат `/mcp` или `claude mcp list` оказался в трансляции, снимке экрана, сообщении коллеге либо в журнале, отправленном за пределы устройства, в том числе автоматически, считайте ключи MCP-конфигураций раскрытыми и замените их. Если данные не покидали ваш компьютер, достаточно установить обновление. Дополнительный материал о MCP-серверах и готовых конфигурациях: [MCP-серверы Claude Code](https://ailoot.ai/blog/ru/mcp-servers-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.
## Как обновить программу и проверить правила?
Кратко
Узнайте версию командой `claude --version`, установите свежий выпуск и проверьте правило на безопасном файле без секретов: добавьте для него deny, попросите агента прочитать его и убедитесь, что сообщение об отказе указывает на ваше правило.
1. **Определите установленную версию.** Запустите в терминале `claude --version`. Исправления описанных сбоев появились в версиях 2.1.268 и 2.1.269. В версиях ниже 2.1.268 их ещё нет, хотя риск конкретного сбоя зависит от используемых путей, команд и правил.
2. **Установите обновление.** Пошаговые действия и разбор проблем описаны в руководстве [обновление Claude Code до последней версии](https://ailoot.ai/blog/ru/update-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 не видит файлы проекта](https://ailoot.ai/blog/ru/claude-code-cant-see-project-files/).
## Если пока нельзя обновиться
Иногда обновление приходится перенести: например, изменения среды запрещены, компьютер управляется организацией или нужно завершить текущую задачу. До установки обновления можно уменьшить вероятность описанных проблем:
- указывайте 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` и токенов в ошибках плагинов. Проверьте версию, обновитесь до последней и испытайте правило на тестовом файле, описанном выше. Отказ с названием правила подтверждает, что оно сработало в этом испытании. Одного наличия правила в настройках для проверки недостаточно.
### Источники
- Официальный журнал изменений Claude Code (записи для 2.1.268, 2.1.269 и 2.1.270):
- Даты выпуска версий Claude Code в npm:
- Документация Claude Code по разрешениям и синтаксису deny/ask/allow:
- Официальные выпуски Claude Code на GitHub:
Для дальнейшей работы с моделями можно перейти в [Ailoot](https://ailoot.ai/).
## Вопросы и ответы
### Как проверить правило deny, не раскрывая настоящий секрет?
Создайте файл с безвредным текстом, запретите Read для этого файла, перезапустите сессию и попросите агента прочитать его. Ожидайте отказ со ссылкой на правило. Не проверяйте потенциально неработающую защиту на настоящем .env.
### Доказывает ли один успешный отказ безопасность всех разрешений?
Нет. Он проверяет только конкретный файл и способ доступа. Изучите активные правила через /permissions и испытайте остальные необходимые пути и случаи, включая пути через символические ссылки, если вы их используете.
## Ailoot · Компания и портфель её проектов
Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI.
Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно.
Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.