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 cumulative delay 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 startup-only shape is what makes the symptom confusing. The same machine can be fine all afternoon and then fail on the next launch, because the scanning cost lands while modules load rather than while you work. The thing to look for is an empty Extension Host log. That empty log is, I suspect, why this gets triaged as a broken extension. Nothing wrote to it, so it looks like nothing ran.

Wasted attempts are where the cost shows up. Reinstalling and disabling extensions are, to be fair, reasonable moves for a genuinely broken install, and neither one reduces per-file scanning latency, so the machine keeps failing in the same place. What tends to follow is a support ticket about an install problem, and the scanner is still there.

Add the following to your security product's exclusion list. On Windows you cover three processes and two install paths. On macOS you exclude the app bundle.

Which column applies depends on how Cursor reached the machine. A per-user install lives under %LOCALAPPDATA%; a machine-wide one under %ProgramFiles%. Fleets tend to end up holding both, as it happens, because installs accumulate and nobody re-images a laptop to tidy up a path. Adding only one column fails quietly. The change looks successful in the console, and everyone on the other install layout keeps timing out exactly as before. %LOCALAPPDATA% also resolves per user account, so check how your console expands it before assuming one entry covers every profile on a machine.

Process exclusions are half the job. Add the install directory as a path exclusion too, so file I/O is skipped no matter which process triggers it. The path differs by platform, as shown below.

All three Windows executables sit inside the two directories you are already excluding by path, so the process list adds no files the path list does not already cover. Which of the two a given product honours is a property of that product, and the docs do not try to sort it out for you. They say add both. The macOS side names one process and one path with no explanation of the asymmetry, so I would not read it as the simpler platform, only the less enumerated one. If a Mac has Cursor installed outside /Applications, the path exclusion has to follow the app.

One piece of standard antivirus advice does not transfer here. The usual reflex with slow tooling is to exclude the source tree or the build output, and that is a much bigger security decision, because your repository is user-generated content while the mechanism on this page is Cursor reading its own bundled JavaScript at startup. Keep the exclusion inside the install directory. If a reviewer asks whether this weakens coverage, say that it narrows what the scanner inspects, and that the narrowing covers only Cursor's own binaries and bundled JavaScript.

If you don't know which products are active, these commands help you locate 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

• Reading fltmc: standard Windows drivers you can ignore include WdFilter, storqosflt, wcifs, CldFlt, bfs, FileCrypt, luafv, Wof, FileInfo, npsvctrig, bindflt and UnionFS. Other drivers are likely third-party security software.
• Reading the environment-variable check: if it returns any results, an EDR product is injecting code into every new process on the machine, and an exclusion may be necessary.

Skipping this step is how the whole exercise fails. Exclusions get added in whichever console someone remembers, the driver actually doing the scanning belongs to a different product, and the team concludes that exclusions do not help. fltmc is the cheap corrective. It lists the filter drivers loaded on that machine, and anything in the output beyond the standard Windows set has an owner you can go and find.

The environment-variable check answers a different question from the file-scanning one. Any result there means an EDR is injecting code into every new process, which the docs treat as its own reason an exclusion may be needed. Whether a path exclusion on the install directory does anything about injection, the page does not say either way, which makes it a question for whoever owns the EDR rather than something to guess at.

Whoever administers the security product, which on most teams is not the person who cannot start Agent. That split is usually why this drags on inside a managed fleet.

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

A managed fleet has no such shortcut. The exclusions have to go into the products' management consoles, and those consoles are administered by security or IT. Not always the same team, either. The instinct is to file a ticket describing the symptom and let them investigate, and I think that gets it backwards: run the identification commands yourself first, then file the ticket as a change request.

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

There is one test that settles it: restart Cursor and run Agent. If Agent works without timing out, the exclusions took effect. Work through the steps below in order.

1. 1Run the identification commands to determine 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 order is load-bearing in two places. The restart comes before the test because the mechanism is startup-time. A session that is already running holds its modules in memory, so it will pass a test that proves nothing about the exclusion. Support sits last in the checklist for a related reason, since the diagnostic output only means something once the exclusions are in place. A log from before that only shows the timeout you already knew about, which is not much for anyone to work with.

Treating the Extension Host log as the check was my own first instinct, since it is the artifact you can point at. It is the weaker signal. A populated log tells you startup got further than it did before, so run Agent as the actual test and keep the log as corroboration for the ticket.

Check that the exclusion actually reached the machine, before anything else. A policy that exists in the console but has not synced to the laptop produces exactly the same symptom, so confirm the sync state on the machine itself.

Then re-run fltmc there and compare it against the standard Windows driver list. A third-party filter driver still loaded is where this usually lands, either because a second product was never identified or because the exclusion path did not match what the product expects. The %LOCALAPPDATA% entry is worth re-reading character by character.

If the drivers look clean and Agent still fails, separate out 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 rather than the endpoint side. A machine that now writes normal Extension Host output at startup and still cannot finish an Agent run is probably in that second category.

Only then is it a support conversation. By that point you have something worth sending: the exclusions you applied and an Extension Host log from a post-exclusion start. Export the logs and hand over both.