Домашний ПК, на котором почти круглосуточно работают Claude Code и Codex, начал подвисать. Диагностика в описанном кейсе дала две причины, и обе не связаны с железом.
Первая: встроенный антивирус Windows проверяет в реальном времени каждый созданный и изменённый файл. Агент за день создаёт и переписывает десятки тысяч файлов, и каждая проверка уходит в процессор. Вторая: агентам в инструкции прописано работать только на диске D, но системный диск C всё равно заполнялся, потому что кеши пакетов, данные Docker и временные файлы запускаемых ими программ по умолчанию пишутся в AppData.
После исключений в Defender и уборки на C загрузка процессора упала с 67% примерно до 12%, без замены железа и переустановки системы (разбор кейса на Habr). Ниже порядок диагностики и настройки: от подтверждения виновника через PowerShell до Dev Drive.
В чём проблема: агенты работают круглосуточно, а ПК начинает подвисать
Агентный кодинг меняет профиль нагрузки на машину. Пользователь сидит в редакторе и occasionally запускает сборку, а агент делает это циклами: ставит зависимости, компилирует, гоняет тесты, откатывает изменения и запускает всё заново, часто в отдельной копии проекта под каждую задачу. Файловая система получает поток операций, которого при ручной работе не бывает.
Симптом при этом выглядит обманчиво: пользователь не делает ничего тяжёлого, а кулеры шумят и курсор дёргается. В диспетчере задач картина складывается в процесс Antimalware Service Executable, который ест процессор.
Почему нагрузка появляется именно с агентами, а не при обычной работе
Человек за день меняет десятки файлов. Агент меняет десятки тысяч: установка пакетов разворачивает дерево зависимостей, сборка пишет промежуточные артефакты, тесты создают временные каталоги, а отдельная копия проекта под задачу умножает это всё на число параллельных сессий. Defender открывает и проверяет каждый такой файл.
Отсюда разница в поведении: ручная работа даёт редкие всплески, агентная - ровную и длинную полку нагрузки на CPU, которая держится часами. Если параллельных агентов несколько, к проверке файлов добавляется конкуренция за ядра: в отдельном кейсе с 25 агентами на RTX 5090 узким местом оказался именно процессор, а не видеокарта (разбор с 25 агентами).
Конкретные цифры вроде числа проверок в секунду зависят от размера файлов, исключений и версии антивируса, поэтому ориентируйтесь на собственный отчёт Defender, а не на чужие замеры.
Как проверить, что виноват Windows Defender: отчёт через PowerShell
Гадать не нужно: Defender умеет писать отчёт о собственной работе. Откройте PowerShell от имени администратора и убедитесь, что каталог для файла отчёта существует (в примере это C:\Temp; если папки нет, создайте её).
Запись работы антивируса на пару минут:
New-MpPerformanceRecording -RecordTo C:\Temp\defender.etlПока идёт запись, запустите агента на типовой задаче: установка пакетов, сборка, тесты. Затем остановите запись (Ctrl+C в консоли) и прочитайте отчёт:
Get-MpPerformanceReport -Path C:\Temp\defender.etl -TopProcesses 10 -TopExtensions 10 -TopFiles 10Отчёт покажет, чьи файлы Defender проверял дольше всего. Если наверху node, git и папки ваших проектов, причина найдена: процессор грузит сканирование файлов, которые создают агенты.
Дополнительных параметров к этим командам не нужно. Если запись не создаётся, проверьте права администратора и свободное место на диске, куда пишется ETL.
Решение №1: исключения в Windows Defender для папок и процессов агентов
Исключения добавляются через Add-MpPreference. Рабочая папка, где агенты создают файлы:
Add-MpPreference -ExclusionPath "D:\Work"Программа агента:
Add-MpPreference -ExclusionProcess "C:\путь\к\программе\agent.exe"В описанном кейсе исключили рабочие папки, где агенты создают файлы, и сами программы: Claude Code, Codex, Antigravity, Cursor. Путь к исполняемому файлу проще всего узнать в свойствах ярлыка или через Get-Process, когда агент запущен, и подставить фактический путь вместо примера.
Проверить текущий список можно командой Get-MpPreference, посмотрев поля ExclusionPath и ExclusionProcess. Исключения не выключают защиту целиком: остальная система проверяется как раньше.
Исключение папки или процесса: что выбрать и чем рискуете
Разница в охвате. Исключение папки действует только внутри неё: если Defender что-то пропустит, пропустит в одном каталоге с кодом. Исключение программы шире: Defender перестаёт проверять файлы, которые эта программа открывает и пишет, в любой папке, включая системные.
Практический порядок такой: сначала исключите рабочие папки проектов и повторите отчёт Defender. Если нагрузка осталась и в отчёте наверху процесс агента, добавляйте исключение программы. Агенты качают пакеты из интернета, поэтому исключать стоит папки с кодом, а не «Загрузки» и не целый диск.
Цена решения честная: в исключённых папках Defender больше ничего не поймает. Чем шире доступ агента к файловой системе, тем дороже ошибка: известен случай, когда субагент Claude Code рекурсивно удалил домашнюю папку и потерял около 116 ГБ данных (разбор инцидента). Исключения из антивируса этот риск не создают, но напоминают, что агент с широкими правами требует бэкапов и аккуратных инструкций.
Решение №2: почему диск C забивается, хотя агентам велено работать на D
У всех агентов в инструкциях записано работать только на диске D. Проекты действительно лежат на D. Системный диск C при этом заполнялся, и это главный вывод материала: инструкция управляет действиями агента, но не тем, куда пишут запускаемые им программы.
Виновники - кеши пакетов, данные Docker и временные файлы инструментов, которые агент вызывает. Эти программы живут по своим настройкам по умолчанию и складывают данные в AppData в профиле пользователя на C. Агент тут лишь триггер: он запускает npm, Docker или сборщик, а те пишут туда, где им прописано конфигурацией.
В исходном разборе кейса вторая причина обозначена кратко, без разбора конкретных каталогов и версий инструментов. Поэтому дальше речь о механике, которую стоит проверить на своей машине: пути зависят от версии npm, Docker Desktop и режима WSL.
Как найти, что именно занимает место на диске C
Чистить наугад бессмысленно. Посчитайте размеры каталогов в AppData и отсортируйте по убыванию: этот скрипт выведет 15 самых тяжёлых папок в LocalAppData.
Get-ChildItem "$env:LOCALAPPDATA" -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object {
$size = (Get-ChildItem $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue |
Measure-Object Length -Sum).Sum
[pscustomobject]@{ Folder = $_.Name; GB = [math]::Round($size / 1GB, 2) }
} | Sort-Object GB -Descending | Select-Object -First 15Тот же перебор имеет смысл повторить для $env:APPDATA и C:\ProgramData: часть инструментов пишет в Roaming, часть в общий каталог. AppData - скрытая папка, поэтому в скрипте стоит ключ -Force; без прав на отдельные подкаталоги ошибки подавляются через -ErrorAction SilentlyContinue, и такие папки просто не попадут в подсчёт.
Типовые подозреваемые: кеш пакетов npm, хранилище образов и контейнеров Docker, временные файлы сборщиков и тестовых фреймворков. Найденные гиганты в несколько десятков гигабайт обычно и объясняют, почему C тает быстрее, чем вы устанавливаете программы.
Очистка кешей npm и Docker и перенос папок на другой диск
Очистка даёт быстрый результат и не требует переноса. У npm для кеша пакетов есть встроенная команда очистки, её синтаксис менялся между мажорными версиями, поэтому сверьтесь с документацией своей версии. Docker Desktop умеет чистить неиспользуемые образы и контейнеры через свой интерфейс и CLI.
Ограничение простое: кеш вернётся. Следующая установка пакетов и первый запуск контейнеров снова скачают данные из сети, это займёт время и трафик. Если агенты работают круглосуточно, разовая уборка откладывает проблему на дни, а не решает её.
Перенос папок через junction-ссылку решает иначе: программа продолжает думать, что пишет в AppData, а данные физически лежат на D. Создаётся ссылка общим синтаксисом:
mklink /J "C:\Users\<имя>\AppData\Local\<папка-кеша>" "D:\Caches\<папка-кеша>"Порядок важен: остановите агентов и Docker, скопируйте содержимое папки на D, переименуйте или удалите исходный каталог на C, затем создайте ссылку. Если целевая папка на D исчезнет или переедет, ссылка сломается, и инструмент начнёт писать заново в пустой каталог на C. Обновления и установщики некоторых программ не любят подменённые пути, поэтому после переноса проверьте, что npm и Docker действительно работают, а новые файлы появляются на D.
Dev Drive на Windows 11: когда стоит использовать
В Windows 11 есть отдельный диск для разработки, Dev Drive. Defender проверяет его в облегчённом режиме и не тормозит запись. Это компромисс между «проверять всё» и «не проверять ничего»: код остаётся под защитой, но файловые операции агентов перестают упираться в антивирус.
Ограничения стоит учитывать заранее. Dev Drive доступен только на Windows 11, требует выделенного тома или виртуального диска, а проекты, кеши и рабочие каталоги агентов нужно осознанно перенести на него. Он не заменяет исключения для программ агентов: если нагрузку создаёт сам процесс, антивирус придётся ограничивать отдельно.
Критерий выбора простой. Много файловых операций и есть возможность выделить отдельный том: Dev Drive даёт стабильный эффект и не требует отключать защиту. Нужен быстрый точечный результат на существующей системе: начните с исключений для папок проектов.
Что получилось в итоге и как закрепить результат
В описанном кейсе загрузка процессора упала с 67% примерно до 12% без замены железа и переустановки Windows. Проверить себя можно теми же инструментами, что и до настройки: повторите запись и отчёт Defender, посмотрите на Antimalware Service Executable в диспетчере задач под нагрузкой агентов, оцените свободное место на C через тот же скрипт по AppData.
Закрепление сводится к трём шагам. Исключения для рабочих папок и, если нужно, для процессов агентов. Перенос кешей npm и хранилища Docker на D через junction-ссылки с проверкой после обновлений. Dev Drive, если система на Windows 11 и есть куда выделить том.
И главный вывод, ради которого стоило разбирать кейс: инструкция управляет агентом, но не настройками программ, которые он запускает. Хотите, чтобы данные не оседали на C, меняйте конфигурацию инструментов и проверяйте результат отчётом, а не формулировкой в промпте.