Cursor Enterprise Deployment Patterns: MDM & Package Managers

How you distribute depends on who owns the machine. IT-managed fleets go through MDM; developer-owned boxes use package-manager scripts; small pilots can just download the build.

The method also settles where the application lands on disk, which is why it outlives the rollout. Cursor's endpoint-security guidance names two Windows locations, %LOCALAPPDATA%\Programs\cursor\ for a user install and %ProgramFiles%\cursor\ for a system install, and antivirus exclusions have to point at whichever one your machines actually have.

A fleet that grew half through MDM and half through people installing it themselves needs both paths listed. Endpoint security has the full exclusion set.

For a pilot of six or eight, MDM is probably more setup than it saves. Direct download and a line in the onboarding doc gets everyone running, and the version drift you are avoiding is not costing you anything yet. The threshold is less a headcount than a question. Whether anyone is being asked to prove which build the team is on.

Cursor documents MDM deployment for three vendors: Jamf, Kandji and Microsoft Intune. Download the relevant build from cursor.com/download and follow your vendor's standard app deployment workflow. Cursor does not push or manage files through your MDM. Configuration and update cadence are owned by your IT or security team.

Vendor choice matters less than policy format, though, since that is where the per-OS work actually lands. Windows takes policies through Registry-based Group Policy, macOS through a .mobileconfig configuration profile, and Linux reads ~/.cursor/policy.json on Cursor 2.0 and later. Reference profiles ship inside the macOS app bundle at /Applications/Cursor.app/Contents/Resources/app/policies/, which is quicker to copy from than to write from scratch.

Push the application and the policy profile as two separate runs. Combine them and a failed first sign-in leaves you two suspects, the package and the profile, with no way to tell them apart without pulling a machine off someone's desk. The gap also buys a confirmation that the build launches on your standard image, which is probably the step people skip.

Hooks (scripts that run at specific points in the Cursor agent workflow) can reach developer machines three ways:

• Project hooks: commit .cursor/hooks.json (plus any scripts under .cursor/hooks/) to the repo so every engineer gets them on clone. The workspace has to be trusted before they run.
• MDM-based distribution: place hooks.json per user at ~/.cursor/hooks.json, or system-wide at /Library/Application Support/Cursor/hooks.json on macOS, /etc/cursor/hooks.json on Linux and WSL, C:\ProgramData\Cursor\hooks.json on Windows.
• Cursor cloud distribution: configure hooks in the Enterprise admin dashboard and Cursor automatically delivers them to every client machine when a team member logs in. No MDM required.

Cloud distribution is the simplest route if you are already on Enterprise. Hooks are configured in the web dashboard, delivered when a team member logs in, then re-synced every thirty minutes, so an edit made before standup is on the fleet by mid-morning. It also targets by operating system, which saves maintaining one script that branches on platform.

Four locations can define the same hook, and all of the matching ones run. Precedence only settles disagreements: when two hooks return conflicting responses, Cursor merges them highest-first, Enterprise then Team then Project then User. A system-wide hook pushed by MDM does not stop the one an engineer committed to the repo from running, it just wins the argument about what the answer should be. When a hook fires and the decision is not the one the repo asked for, that ordering is what I would check first.

The cloud-agent side carries its own limits. Cloud agents run command-based hooks only, and they never read ~/.cursor/hooks.json, because the VM has no access to a developer's home directory. A hook that works on a laptop and does nothing in a cloud run is usually one of those two, though the per-user MDM path is the route that walks straight into it.

Most corporate proxies work transparently. The common failure is a network that blocks HTTP/2 streaming, and Zscaler is the documented example. On one machine, switch HTTP Compatibility Mode to HTTP/1.1 under Cursor Settings → Network and restart. Across a fleet, the NetworkDisableHttp2 MDM policy does the same thing without asking anyone to click it.

My first instinct was to set that policy fleet-wide as insurance. That gets it backwards: Cursor already falls back to HTTP/1.1 server-sent events on its own when a proxy breaks the stream, and that fallback was built for Zscaler specifically, so the policy forces what the client otherwise handles transparently. Scope it to the sites behind the proxy that needs it, and use the Run Diagnostics button under Settings → Network to test connectivity before you decide.

For everything else, the fix depends on where the network breaks the connection. The table maps each symptom to the setting that resolves it.

The certificate row is the one this page cannot finish for you. Adding your internal CA to the system trust store handles the client side; the proxy side, meaning firewall allowlists and SSL-inspection exclusions, sits on network configuration. Settle that first or the client-side fix will look like it failed.

Update cadence is an MDM policy called UpdateMode, and it takes five values. none disables automatic updates, manual lets users check for themselves, start checks on launch, default behaves the same as start, and silentlyApplyOnQuit downloads in the background and applies when Cursor quits. Cursor publishes builds for all platforms at cursor.com/download, so pinning a version means deploying that build through your MDM and setting the policy to match.

On a managed fleet I would reach for silentlyApplyOnQuit before none. It keeps machines current without interrupting anyone mid-session, and it steps around the macOS problem: Electron makes Cursor updates require administrator privileges there, so on a fleet where developers are standard users, an update prompt that lands mid-task is one they cannot complete. Cursor's own suggestions for that case are MDM deployment, an automated tool such as Installomator, or UpdateMode set to none.

Pinning has a clock attached to it, which is the part that surprises people. Cursor runs two version floors: a minimum supported version, where users on older builds see a dismissable warning, and a minimum allowed version, where the error cannot be dismissed and they have to upgrade. A release becomes eligible for the first about two months after its GA date, and for the second about three months after. Freeze a build with UpdateMode set to none and leave it there, and roughly a quarter later your fleet hits the error nobody can click past.

A pin needs a review date. Whoever sets it should book the revalidation in the same change ticket, two months out, while the warning is still dismissable.

This is the single most common enterprise misconception about deploying Cursor. Self-hosted runtimes move where tool calls execute: the shell that clones your repo, runs commands, edits files and drives the browser. They do not move model inference, and they do not move the agent loop, which Cursor documents as running in its cloud on all three runtimes. Every completion is still an outbound call to a model provider.

What a private worker buys you is network reach. Because it runs where your internal services live, the agent can talk to an internal-only Git host or a private package registry, and to MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers you keep off the public internet.

Whether you need one at all, and which runtime fits, is a separate call and probably the one to make first. Choosing a Cloud Agent runtime walks the decision tree Cursor publishes.

Cloud agents run with broad capability by default, so the Enterprise admin dashboard exposes per-org controls over what a run can reach and how long it can run. Set these before you turn agents loose on real repos.

Of the six, domain allow-lists and branch control are the two I would have in place before anyone gets access, because they bound what a run can reach and what it can land. Run-time caps and model selection can follow a week later; a wrong value there shows up on the bill. Confirm environment isolation rather than assuming it, since a run that inherits state from the one before it is hard to spot after the fact.