# Агент настроил себе защиту и перестал запускаться: как править настройки безопасно

Настройка безопасности ИИ-агента ломает запуск, если правка ушла не в тот раздел. Резервная копия, черновик, новый чат и проверка запрета на файле-приманке.

URL: https://posts.danashkin.ru/guides/agent-pravit-svoi-nastroyki
Обновлено: 2026-10-09

---

## Коротко

**Главное**

- Когда агент сам дописывает себе правила безопасности, он правит файл настроек, без которого приложение не запускается. Одна неверная строка - и агент перестаёт отвечать, а починить себя уже не может.
- Порядок, который спасает: сначала документация твоей версии, потом резервная копия конкретного файла, потом правка в отдельном черновике, проверка и только затем замена.
- Отчёт агента «защита настроена» ничего не доказывает. Запрет проверяют на файле-приманке с выдуманным содержимым: агент в новом чате должен упереться в стену.
- Режим без подтверждений включают последним, после проверки запретов, а не перед ней.

## Почему агент может сломать сам себя?

**Главное**

Настройки агента - обычный текстовый файл, который приложение читает при запуске. Если агент записал туда правило в форме, которую приложение не принимает, оно перестаёт загружаться. Агент живёт внутри этого приложения, поэтому исправить ошибку его же руками уже нельзя.

Недавно я разбирал случай, который хорошо показывает механику. Агенту дали задание настроить себе защиту: запретить чтение файлов с ключами. Он дописал правило в свой файл настроек.

Сначала перестали отправляться сообщения. После перезапуска приложение вообще отказалось стартовать с ошибкой «не удалось загрузить конфигурацию, не запустится, пока не будет исправлено».

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

Разберём простым языком, что пошло не так и какой порядок от этого защищает.

## Две типичные поломки в файле настроек

**Главное**

Обычно две вещи. Правило записано в форме, которую твоя версия приложения не поддерживает. Или строка оказалась не в том разделе файла: в формате TOML всё, что стоит ниже заголовка раздела, относится к этому разделу, и перенос строки меняет смысл.

В том случае ошибок было две, и обе типичные.

**Неподдерживаемая форма правила.** Приложение ответило так:

```text
filesystem glob path `**/*.env` only supports `deny` access;
use an exact path or trailing `/**` for `deny` subtree access
```

Переводя на человеческий: шаблон «все файлы .env во всех папках» допустим только в одной форме запрета, а агент записал его в форме, которую валидатор отверг. Сам по себе шаблон не запрещён, неправильно было его оформление.

**Строка не в своём разделе.** Агент сам признал в отчёте, что параметр, который должен стоять в начале файла, попал внутрь раздела. В формате TOML, на котором написаны настройки Codex, раздел начинается с заголовка в квадратных скобках, и все строки ниже принадлежат ему до следующего заголовка. Файл при этом выглядит синтаксически нормальным, но значит уже другое.

| Где живут настройки | Codex | Claude Code |
|---|---|---|
| Для всех проектов на компьютере | ~/.codex/config.toml | ~/.claude/settings.json |
| Для одного проекта | .codex/config.toml в папке проекта | .claude/settings.json в папке проекта |
| Формат | TOML | JSON |

Знать эти адреса стоит заранее. Когда приложение не запускается, искать их в панике сложнее.

## Почему один и тот же промпт то работает, то нет?

**Главное**

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

Здесь ловушка для всех, кто пишет инструкции для команды. У автора инструкции всё работает, потому что его приложение уже настроено, и правка ложится на готовый файл. На чистой установке тот же текст промпта приводит агента к другому решению.

Приложения агентов обновляются часто, и вместе с ними меняется синтаксис настроек. Модель знает формат на момент своего обучения, а у тебя может стоять версия новее. Поэтому проверка актуальной документации должна идти до правки, а не после. В разобранном случае порядок был обратный: сначала правка, потом сверка синтаксиса.

Вывод для тех, кто готовит такие инструкции для коллег: промпт «настрой защиту» лучше заменить готовым, проверенным на чистой установке блоком настроек и командой «вставь этот блок, ничего не меняя». Тогда у всех получится одинаковый файл, и если что-то пойдёт не так, ошибка будет одна на всех и найдётся быстрее. А задачу агента сузить до проверки: сверить блок с документацией установленной версии и сообщить о расхождениях до вставки, а не исправлять их самостоятельно.

Об этом же явлении в более общем виде писал в материале про то, что [инструкция устаревает за месяц](/guides/instrukciya-ustarela-za-mesyac).

## Порядок безопасной настройки за шесть шагов

**Главное**

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

1. **Сверь синтаксис с документацией твоей версии**

   Попроси агента сначала открыть официальную документацию по настройкам и проверить, какие формы правил поддерживает установленная версия. Только потом писать правило.

2. **Сделай резервную копию конкретного файла**

   Скопируй файл настроек рядом с датой в имени. Не «сделай бэкап», а конкретный путь к конкретному файлу, и убедись глазами, что копия появилась.

3. **Пусть агент пишет в черновик**

   Новые настройки сначала в отдельный файл-кандидат. Рабочий файл не трогаем, пока кандидат не проверен.

4. **Проверь кандидата**

   Три вопроса: файл читается как TOML или JSON без ошибок; приложение принимает такие правила; корневые параметры стоят в начале файла, а не внутри разделов.

5. **Замени и открой новый чат**

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

6. **Проверь запреты на приманке**

   Файл с выдуманным содержимым под запретом и новый чат, который пытается его прочитать. До этой проверки защита не считается настроенной.

**Если приложение уже не запускается**

Найди файл настроек через Finder или проводник, открой его в обычном текстовом редакторе и верни содержимое из резервной копии. Нет копии - удали последние добавленные строки. Терминал для этого не обязателен, хотя с ним быстрее: как перестать его бояться, разбирал в статье про [терминал для непрограммиста](/guides/terminal-dlya-neprogrammista).

## Как проверить, что запрет действительно работает?

**Главное**

Создать файл-приманку с выдуманным содержимым, например test.env со строкой ПРОВЕРКА-123, и в новом чате попросить агента его прочитать. Если агент прочитал - запрета нет, что бы он ни писал в отчёте. Проверять на настоящих ключах нельзя: проверка сама станет утечкой.

В разобранном случае после восстановления был ещё один показательный момент. Агент честно написал в ответе, что запреты он будет соблюдать, но автоматическая блокировка в текущем чате не подтверждена. Это две разные вещи: «агент обещает не читать» и «приложение не даст прочитать».

Обещание агента держится, пока он помнит правило в контексте. Блокировка на уровне приложения работает всегда. Как отличать отчёт агента от результата вообще, разбирал в материале про то, [как ловить «готово» без результата](/guides/agent-otchitalsya-a-rezultata-net).

Проверка на приманке выглядит так:

1. Создай в папке проекта файл с именем, которое попадает под запрет. Внутри одна выдуманная строка.
2. Открой новый чат и попроси агента показать содержимое этого файла.
3. Правильный результат - отказ приложения или явная ошибка доступа. Неправильный - агент выводит «ПРОВЕРКА-123».
4. Повтори с поиском по папке: запрет должен срабатывать и тогда, когда агент ищет текст, а не открывает файл напрямую.
5. Удали приманку.

**Чего не делать**

Не проверяй запрет на реальном файле с ключами. Если запрет не работает, ключи окажутся в истории чата. Где держать ключи так, чтобы агенту не было нужды их читать, разбирал в материале про [хранение ключей своего продукта](/guides/gde-hranit-klyuchi-svoego-produkta).

## Когда включать режим без подтверждений?

**Главное**

Последним. Режим, в котором [ИИ-агент](/concepts/ai-agent) выполняет действия без вопросов, безопасен ровно настолько, насколько надёжны запреты. Пока приманка не проверена, агент должен спрашивать разрешение на каждое действие.

Логика простая. Подтверждения - это ручной фильтр, запреты - автоматический. Убирать ручной фильтр, пока не проверен автоматический, значит остаться без обоих.

Порядок такой: запреты записаны, приложение запускается, приманка не читается, поиск по приманке не работает. Только после этого переключаешь режим. Если работаешь в группе, этот порядок тем более важен: у кого-то из коллег шаг с настройкой мог пройти иначе.

Какие запреты ставить в первую очередь и что агент вообще видит на диске, разбирал в статье о том, [что агент делает на твоём компьютере](/guides/chto-agent-delaet-na-tvoem-kompyutere).

## Частые вопросы

**Главное**

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

### Частые вопросы

**Можно ли вообще поручать агенту настройку его же защиты?**

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

**После одного и того же шага сломалось у нескольких людей. Это сервер?**

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

**Поможет ли откат через git?**

Если файл настроек лежит в папке проекта под git, да: вернёшь прошлую версию одной командой. Глобальные настройки в домашней папке обычно не под git, поэтому для них нужна отдельная копия. Как откатывать изменения агента в проекте, разбирал в материале про [откат изменений](/guides/kak-otkatit-izmeneniya-agenta).

**Нужно ли проверять запреты после обновления приложения?**

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

## Главный вывод

**Главное**

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

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

Практический шаг на сегодня: найди у себя файл настроек агента, сделай его копию с датой в имени и создай приманку test.env. Десять минут, и ты будешь знать, защищён ли ты на самом деле.

Ты уже проверял свои запреты на приманке или пока веришь отчёту агента?

### Источники

- [Configuration Reference - где лежит config.toml Codex и как устроены его правила, ChatGPT Learn](https://learn.chatgpt.com/docs/config-file/config-reference)
- [Settings files and precedence - где лежат файлы настроек Claude Code и пример запрета на чтение .env, Claude Code Docs](https://code.claude.com/docs/en/settings)
- [Configure permissions - как устроены разрешения и запреты в Claude Code, Claude Code Docs](https://code.claude.com/docs/en/permissions)
- [TOML v1.0.0 - спецификация формата: таблицы и принадлежность строк разделу](https://toml.io/en/v1.0.0)