My PC started lagging once AI agents moved in. Two causes, both fixable by hand

At some point my home PC started to lag. Not crash, just hesitate: a window takes a second to open, the cursor freezes for a beat. That machine runs AI coding agents almost around the clock, Claude Code and Codex, editing code, installing packages, running builds and tests.

I didn't go digging myself. I asked one line in a chat: "Why is my home PC lagging? Look at what's loading the CPU and disk and name the main cause. Don't change anything." The chat reached the computer, looked at processes and disks, and came back with two causes. I would have spent a long time finding either of them.

Cause one: Defender scans every file the agents write

Windows' built-in antivirus checks every created and modified file in real time. A person changes a few dozen files a day. An agent changes tens of thousands: package installs, builds, a separate copy of the project for every task. Defender opens and scans each one. In Task Manager it shows up as "Antimalware Service Executable" eating CPU while you seem to be doing nothing.

How to check by hand. In an elevated PowerShell, record Defender's work for a couple of minutes:

New-MpPerformanceRecording -RecordTo C:\Temp\defender.etl
# let your agents work for a couple of minutes, then press Enter
Get-MpPerformanceReport -Path C:\Temp\defender.etl -TopProcesses 10 -TopExtensions 10 -TopFiles 10

The report shows whose files took Defender the longest. If node, git and your project folders are at the top, that's your answer.

Two ways to deal with it:

• Exclude the agents' working folders from scanning. The price is clear: Defender won't catch anything in those folders any more. Agents download packages from the internet, so exclude only code folders, not Downloads and not a whole drive.
• Windows 11 has a Dev Drive, a separate volume for development work. Defender scans it in a lighter mode that doesn't hold up writes. It's a middle ground between "scan everything" and "scan nothing".

We took the first route and went a bit further. We excluded the working folders where agents create files, and the agent programs themselves: Claude Code, Codex, Antigravity, Cursor.

Add-MpPreference -ExclusionPath "D:\Work"
Add-MpPreference -ExclusionProcess "C:\path\to\agent.exe"

Excluding a program is a bigger step than excluding a folder. Defender stops scanning the files that program opens and writes, in any folder. Agents pull other people's packages from the internet, so I took that risk on purpose: it's a work machine, and the lag was costing me more. If that's not true for you, start with folders only, or with a Dev Drive.

Cause two: the agents wrote to drive C even though they were told not to

Every one of my agents has the same line in its instructions: work on drive D only. The projects really are on D. And yet the system drive C kept filling up.

It turned out it wasn't the agents writing there, it was the programs they run, and the agent apps themselves: package caches, app data, temp files. By default all of that lands in the user's AppData on drive C. The agent honestly works in D:\, and the gigabytes pile up in C:\Users\…\AppData.

This is the part worth remembering: an instruction controls what the agent does, not where the programs it launches write.

How to see which AppData folders are the biggest:

Get-ChildItem $env:LOCALAPPDATA, $env:APPDATA -Directory -ErrorAction SilentlyContinue | ForEach-Object {
  $s = (Get-ChildItem $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum
  [pscustomobject]@{ Folder = $_.FullName; GB = [math]::Round($s / 1GB, 2) }
} | Sort-Object GB -Descending | Select-Object -First 10

On my machine the top entries were the npm cache (including the npx cache, which lives inside it) and Docker's data. Agents run all sorts of things through npx, and every version stays in the cache. We cleaned up like this:

npm cache clean --force          # npm cache, including packages fetched by npx
docker system df                 # how much images, containers and build cache take
docker system prune              # remove stopped containers and anything unused

Cleaning treats the symptom: in a month the caches grow back. So we also moved the folders themselves to D and left a link on C pointing to the new place. Programs still write "to AppData", while the files physically live on D. Close the program that owns the folder first:

robocopy "$env:LOCALAPPDATA\SomeTool" "D:\AppData\SomeTool" /E /COPY:DAT
Rename-Item "$env:LOCALAPPDATA\SomeTool" "SomeTool.old"
cmd /c mklink /J "$env:LOCALAPPDATA\SomeTool" "D:\AppData\SomeTool"
# check the program still works, and only then delete SomeTool.old

Some programs offer a cleaner route: tell them to keep their cache elsewhere. For npm, for example: npm config set cache D:\npm-cache.

The result

CPU load dropped from 67% to about 12%. No new hardware, no reinstall: Defender simply stopped re-scanning files we were creating ourselves. The PC stopped lagging, and I went back to work.

What I took from it

• A computer running agents is a different kind of load. It writes files hundreds of times more often, and anything that inspects files starts to drag.
• Checking what the agent does isn't enough. Check where the traces of its work end up.
• You can hand the diagnosis to an AI in one question. Just add "don't change anything" and ask what the conclusion is based on.

I asked through Local Commander, my own project, which lets a chat reach my computers. But both checks above take half an hour by hand without it.

Have your agents ever slowed a machine down in a way you had to hunt for?