Большой репозиторий даёт агенту слишком много поводов отвлечься: сгенерированные артефакты, снапшоты данных, покрытие тестов - всё это раздувает индекс и подмешивается в контекст, не помогая задаче. Инструмент, чтобы это убрать, - файл игнора, предпочтительно .devinignore; в соответствующих поверхностях распознаются и legacy-файлы .codeiumignore и .windsurfignore, а по умолчанию из индекса и так исключаются gitignored-пути, node_modules и скрытые каталоги.
Наивный ход рождается из самого слова "ignore": раз агент это игнорирует, значит, туда можно спрятать секреты и чувствительные данные - .env, ключи, дампы прода - и они в безопасности. Логика соблазнительна своей простотой: одна строка в файле как будто заменяет настройку прав. Именно эта подмена и опасна.
Ломается она на том, что игнор - это про шум, а не про безопасность. Он уменьшает индекс и снижает шанс случайного попадания файла в контекст, но не является универсальной security boundary: фактическое поведение чтения и записи зависит от агента и его настроек, а не от наличия пути в .devinignore. Файл игнора управляет вниманием, а не полномочиями.
Разницу видно уже в документированных мелочах. Так, файлы из .gitignore агент не может редактировать - это функциональное ограничение индексации, а не гарантия, что путь недосягаем во всех сценариях. Игнор говорит движку "не держи это в индексе"; он не говорит операционной системе "не давай процессу это прочитать". Смешивать два уровня - и значит изображать сейф там, где стоит лишь табличка.
Профессиональный приём - развести две задачи по разным механизмам. Для снижения шума и ускорения индекса - .devinignore с явными паттернами. Для реальной защиты - настоящие границы: у Devin Local это permission-правила с явным deny и системный sandbox, ограничивающий, что процесс вообще может прочитать и куда обратиться. Для секретов - не игнор и не деревья файлов, а secret manager, чтобы значения не лежали в репозитории в принципе.
Сам файл при этом остаётся полезным, и вести его стоит аккуратно. Небольшой .devinignore, убирающий из индекса окружения, секретные каталоги, покрытие, сборку и фикстуры с продовыми данными, разом снижает и шум, и случайный контекст. Такой файл читается за секунды и переносится между проектами вместе с репозиторием.
Enterprise может задать игнор глобально: файл .codeiumignore в ~/.codeium/ применяется ко всем рабочим пространствам Devin Desktop на машине. Это удобно для единой политики "не индексировать вот это никогда", но и здесь важно помнить его природу: глобальный игнор шире по охвату, но ровно так же не является границей безопасности - он лишь распространяет правило о внимании на все проекты сразу.
Почему инструмент намеренно не делают security-границей. Игнор - это подсказка индексатору, дешёвая и переносимая, живущая в репозитории рядом с кодом. Настоящая изоляция стоит дороже и живёт на другом уровне - в правах агента и в песочнице ОС. Свести защиту к строчке в текстовом файле значило бы дать ложное чувство безопасности, которое опаснее честного его отсутствия: от видимой таблички перестают ставить настоящий замок.
Цена подмены конкретна. Секрет, "спрятанный" в .devinignore, по-прежнему лежит в рабочем дереве открытым текстом; достаточно другого сценария доступа, другой поверхности или другой настройки - и он прочитан. Хуже того, запись в игнор гасит бдительность: раз "спрятали", про настоящий deny и про secret manager уже не вспоминают. Радиус такой ошибки - утечка, а не лишняя строка в индексе.
Оценку производителя по стоимости индекса стоит держать как ориентир, а не гарантию. На срезе документация называет примерно 5-10 минут индексации и около 300 MB RAM на 5000 файлов и рекомендует держаться в пределах 10 000 файлов на машине примерно с 10 GB RAM. Цифры зависят от машины и проекта, поэтому игнор здесь работает и на производительность: чем меньше лишнего в индексе, тем ближе вы к комфортному диапазону.
Проверять результат нужно по двум разным линиям и не путать их. Для шума и скорости - что индекс уменьшился, лишнее не подмешивается в контекст, индексация укладывается в ориентир. Для безопасности - что секреты защищены не игнором, а deny-правилами, sandbox и secret manager; проверка здесь - попытаться убедиться, что даже без записи в игнор агент не имеет прав прочитать секрет. Типичный провал один: строку в .devinignore принимают за замок. Признак - фраза "это же в игноре" вместо ссылки на permission-правило или sandbox. Сначала назовите настоящую границу - и если её нет, никакой игнор её не заменит.
# .devinignore
.env*
secrets/**
coverage/**
dist/**
fixtures/production-data/**
*.pem
*.p12