Cursor Enterprise Deployment Patterns: MDM & Package Managers

You can deploy Cursor through MDM, a package manager or a direct download, and the right method depends on who owns the machine. IT-managed fleets go through MDM, developer-owned machines can use a package manager or a script, and a small pilot can download the build.

Cursor's quickstart documents its own apt and dnf repositories for Linux. The docs don't mention Homebrew, winget or Chocolatey, so check who maintains the package before you script a fleet around it.

The method can also decide where the application lands on disk, which matters long after the rollout. Cursor's endpoint security guidance names two Windows install locations: %LOCALAPPDATA%\Programs\cursor\ for a user install and %ProgramFiles%\cursor\ for a system install. Antivirus exclusions have to point at whichever one your machines have.

A fleet that grew half through MDM and half through self-installs needs both paths listed. Endpoint security has the full exclusion set.

For a pilot of six or eight people, MDM can cost more setup than it saves. Direct download and a line in the onboarding doc get everyone running, and version drift isn't costing you anything yet. Move to MDM once someone has to prove which build the team runs, however small the team is.

Cursor's docs name three MDM vendors: Jamf, Kandji and Microsoft Intune. Package the build from cursor.com/download and push it with your vendor's standard app deployment workflow. Cursor doesn't deploy or manage files through your MDM, so your IT or security team owns the configuration and the update cadence.

The policy format matters more than the vendor, because that's where the per-OS work 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. A reference profile ships inside the macOS app bundle at /Applications/Cursor.app/Contents/Resources/app/policies/, which is quicker to start from than a blank file.

Edit that reference profile before you deploy it. It sets every policy available in that version of Cursor, and any policy you leave in place is enforced with its default value. Delete the policies you don't need.

Push the application and the policy profile as two separate runs. If you combine them, a failed first sign-in leaves two suspects, the package and the profile, and you can't tell them apart without taking a machine off someone's desk. The gap between runs also lets you confirm that the build launches on your standard image.

Hooks are scripts that run at set points in Cursor's agent loop. Cursor documents three ways to get them onto developer machines.

On Enterprise, cloud distribution covers every member without MDM or a commit to each repository. Hooks arrive at login and re-sync every thirty minutes, so a dashboard edit reaches running clients at their next sync. It can also target by operating system, which saves you maintaining one script that branches on platform.

Hooks can come from four levels, and every matching hook runs. When their decisions conflict, a deny from any level beats ask, and ask beats allow, so an MDM hook's deny always holds. For some other fields, such as the follow-up message, responses merge from Enterprise down to User and the last one wins, so a project hook an engineer committed replaces the MDM hook's value. When a hook's decision surprises you, check these merge rules before you debug the scripts.

Cloud agents have their own limits. They run command-based hooks only, and they never read ~/.cursor/hooks.json, because the VM can't see a developer's home directory. They can also start in a read-only environment where hooks don't run until the agent can write. If a hook works on a laptop but does nothing in a cloud run, check these limits first. A hook that MDM placed at the per-user path never runs in a cloud agent.

Cursor works with most proxy configurations, but HTTP/2 streaming and SSL inspection can break it. Cursor calls SSL inspection one of the most common deployment blockers for enterprise customers.

Some proxies don't support HTTP/2 streaming correctly, and Cursor names Zscaler as the most widely used one with that limitation. On one machine, set HTTP Compatibility Mode to HTTP/1.1 under Cursor Settings → Network, then restart. Across a fleet, the NetworkDisableHttp2 MDM policy does the same without asking anyone to click it.

Don't set that policy fleet-wide as insurance. Cursor already falls back to HTTP/1.1 server-sent events when HTTP/2 streaming fails, and it built that fallback for Zscaler and similar proxies, so the policy forces what the client otherwise handles on its own. Use it on the machines that still fail behind the proxy, and click Run Diagnostics under Cursor Settings → Network before you decide.

For other failures, the fix depends on where the network breaks the connection.

Cursor notes that its services are already encrypted end to end, and it recommends excluding its domains from SSL inspection. If your policy requires inspecting everything, the proxy has to support HTTP/2 bidirectional streaming or let the HTTP/1.1 fallback work, pass server-sent events through without buffering, and allow long-running connections. The domain list and firewall allowlist are on network configuration.

Update cadence is an MDM policy called UpdateMode, and it takes five values. none disables automatic updates, manual lets users check for updates themselves, start checks on launch, default behaves like 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.

Which value fits depends on who can install updates. Electron's limits mean Cursor updates need administrator privileges on macOS, so a developer working as a standard user can't complete an update prompt. For that case, Cursor recommends delivering updates through MDM or a tool such as Installomator, with UpdateMode set to none so users don't see failed update notifications. Where users can install updates, we'd pick silentlyApplyOnQuit, which keeps machines current without interrupting anyone mid-session.

Pinning has a time limit, because Cursor runs two version floors. Below the minimum supported version, users see a dismissable warning. Below the minimum allowed version, they see an error they can't dismiss and have to upgrade.

Cursor's rule of thumb is that a release becomes eligible for the first floor about two months after its GA date, and for the second about three months after. Each bump also depends on how widely newer releases have been adopted. The clock starts at the build's GA date, not the day you pin it. Book the revalidation in the same change ticket, for a date before the build reaches two months past GA, when the warning can start.

No. Self-Hosted Machines move where tool calls run: file edits, terminal commands, computer use and local 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. Cursor runs the agent loop, inference and planning in its cloud on all three runtimes: Cursor-managed Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., My Machines and Team Pools. The worker opens an outbound connection to Cursor, runs the tool calls Cursor sends, and returns the results for the next inference round.

What a self-hosted worker buys you is execution on hardware you control, with that hardware's network access. The agent can reach an internal-only Git host, a private package registry or a command-based 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. server on your network, because the worker reaches them locally. HTTP MCP servers are the exception: Cursor's backend still calls their URLs.

If private network access is your main requirement, Cursor suggests trying managed Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. first, with network controls, a private-network client or private connectivity. Whether you need a worker at all, and which runtime fits, is the call to make before anything else. Choosing a Cloud Agent runtime walks through the decision tree Cursor publishes.

Admins set Cloud Agent controls from the Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. dashboard and the team settings. Enterprise admins can also lock the network policy so users can't override it. Set these before agents work on real repositories.

Set network access before the first agent runs, because it bounds what a run can reach and where it can send data. If your organization approves specific model providers, set model selection before that first run too. Otherwise it can wait, since a wrong default model mainly affects cost and output quality. Isolation and the pull request handoff are built in, so there is nothing to switch on for them.