Cursor Enterprise: Endpoint Security

Cursor's extension host reads JavaScript files from its own install directory at startup. When security software adds per-file scanning latency, the delays add up and can exceed Cursor's startup timeout, and features like Agent fail. Software that injects into processes can cause the same problem.

This mainly affects startup. Once modules are loaded into memory, ongoing file operations are infrequent and unlikely to cause issues.

That timing makes the symptom confusing. A machine can work all afternoon and fail on the next launch, because the scanning cost lands while modules load, not while you work. Look for an empty Extension Host log. It can make the problem look like a broken extension, since nothing wrote to it and so nothing seems to have run.

Reinstalling and disabling extensions are reasonable moves for a broken install. Neither one reduces per-file scanning latency, so the machine keeps failing in the same place, and you can end up filing a ticket about an install problem while the scanner keeps running.

Add the following to your security product's exclusion list. On Windows, that means three processes, each with a user-install and a system-install path, plus three folders. On macOS, you exclude the Cursor.app process and the app bundle.

Which column applies depends on how Cursor reached the machine. A per-user install lives under %LOCALAPPDATA%, and a machine-wide install under %ProgramFiles%. A fleet can hold both layouts when machines got Cursor by different routes. Adding only one column fails quietly: the console shows the change, and everyone on the other layout keeps timing out.

%LOCALAPPDATA% also resolves per user account. Check how your console expands it before you assume one entry covers every profile on a machine.

Add folder exclusions as well, so scanning skips those folders whichever process touches them. The folders differ by platform.

Keep them to Cursor's list: its processes, its install folders and, on Windows, its user data folder. All three Windows executables sit inside the install folders you exclude by path, so the process list adds no files the folder list misses. Whether a product honors the process rule, the folder rule or both depends on that product. Cursor's docs don't say which products honor which, and they tell you to add both.

The macOS list names one process and one folder and doesn't explain why it's shorter than the Windows list. Treat it as less detailed, not as proof that macOS needs less. If a Mac has Cursor installed outside /Applications, the folder exclusion has to follow the app.

One piece of standard antivirus advice doesn't transfer here. With slow tooling, the usual reflex is to exclude the source tree or the build output. That's a much bigger security decision, because your repository holds user-generated content, and the delay on this page comes from Cursor reading its own bundled JavaScript at startup. Cursor's list doesn't include your repository.

The %APPDATA%\Cursor\ folder isn't part of the install directory. It holds user data, settings and workspace storage, and Cursor's docs list it without explaining why or assessing its risk. If a reviewer asks whether these exclusions weaken coverage, list exactly which processes and folders you excluded and what Cursor's docs say each folder holds.

If you don't know which products are active, these commands help you find where exclusions need to go. On Windows, run them in an Administrator PowerShell window.

# Registered AV products
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct |
  Select-Object displayName, pathToSignedProductExe

# Kernel-level filesystem filter drivers
fltmc

# Check for EDR process injection via environment variables
[System.Environment]::GetEnvironmentVariables() |
  Where-Object { $_.Keys -match "BPP|COR_PROFILER|COMPLUS|__COMPAT" }

# Windows Defender status
Get-MpComputerStatus |
  Select-Object IsTamperProtected, RealTimeProtectionEnabled, AMRunningMode

Without this step, exclusions can go into the wrong console. Someone adds them in the product they remember, the driver doing the scanning belongs to a different product, and the team concludes that exclusions don't help. fltmc lists the filter drivers loaded on that machine, and anything beyond the standard Windows set has an owner you can find.

The environment-variable check answers a different question: whether an EDR injects code into every new process, which Cursor's docs treat as its own reason an exclusion may be needed. The docs don't say whether a folder exclusion does anything about injection, so ask whoever owns the EDR.

The change belongs to whoever administers the security product. In a managed fleet, that's security or IT, not the developer whose Agent won't start, and the handoff between them usually slows the fix down.

On a small team, one person may hold both roles. They can add the exclusion, restart, and know within a launch or two whether the scanner was the problem. Try that on one machine before anything fleet-wide, because a negative result saves the security team a change request.

A managed fleet has no such shortcut. The exclusions go into each product's management console, which security or IT administers, and those aren't always the same team. Instead of a ticket that only describes the symptom, run the identification commands yourself, then file the ticket as a change request.

Include the fltmc output from the affected machine, the exact process and path list, and the product you believe owns the driver.

One test settles it: restart Cursor and run Agent. If Agent works without timing out, the exclusions took effect. Cursor's troubleshooting checklist runs in this order.

1. 1Run the identification commands to find which security products are running.
2. 2Add both process and path exclusions for those products in their management consoles.
3. 3Restart Cursor and test Agent. This is the definitive test of whether the exclusions worked.
4. 4If it still fails, export logs and contact Cursor support with the diagnostic output.

The restart comes before the test because the problem happens at startup. A session that is already running holds its modules in memory, so it passes a test that proves nothing about the exclusion.

Support comes last in that checklist, but the logs shouldn't wait for it. Cursor's help center says to collect logs before you change anything, because causes vary, and it calls an empty Extension Host panel a strong diagnostic signal. Export them again if Agent still fails after the exclusions, so support can compare the two.

The Extension Host log is the weaker check. A populated log shows that startup got further than before, so run Agent as the test and keep the log as evidence for the ticket.

First, check that the exclusion reached the machine. A policy that exists in the console but hasn't synced to the laptop produces the same symptom, so confirm the sync state on the machine itself.

Then re-run fltmc on that machine and compare the output with the standard Windows driver list. The likely cause is a third-party driver from a product nobody identified, or an exclusion path that doesn't match what the product expects. Re-read the %LOCALAPPDATA% entry character by character.

If the drivers look clean and Agent still fails, check whether this is a scanning problem at all. Buffering proxies and SSL inspection cause their own Agent timeouts, and those belong on the network configuration side, not the endpoint side. If a machine now writes normal Extension Host output at startup but still can't finish an Agent run, look there first.

At that point, contact Cursor support. Send the exclusions you applied and the logs you exported before and after them.