How to manage Claude Desktop updates across your enterprise fleet

Your security team signed off on Claude Desktop. IT pushed the MSIX package through Intune, following the deployment path that works on locked-down endpoints. Everyone moved on to the next project.

Three weeks later, Anthropic shipped an update that changed behavior your team’s workflows depended on. Half the fleet auto-updated. The other half sat on the old version because the updater needed elevation your managed endpoints refuse to grant. Two different versions in production, two different behaviors, and nobody noticed until a support ticket landed blaming IT for something that “used to work.”

That scenario plays out constantly. Initial deployment gets all the planning and attention. Ongoing update management gets almost none. This is completely backwards. Deployment happens once. Updates happen every week, sometimes more often, for the entire life of the software. Getting the update process wrong means perpetual version fragmentation, security patches sitting unapplied, and new features arriving randomly to random people.

Why update management is harder than deployment

Claude Desktop follows a rapid release cadence. Updates ship weekly, sometimes multiple times in a week when security fixes or critical changes land. This is standard for modern desktop software. It also creates a problem that enterprise IT teams are not used to dealing with from their AI tooling.

The built-in auto-updater works fine on unmanaged machines. Personal laptops, developer workstations with admin access, anything where the user has full control. It downloads the update, applies it, restarts the app. Simple.

On managed endpoints, the updater hits a wall. It needs write access to program directories that your policies lock down. It needs elevation that your endpoint management refuses to grant without explicit approval. It needs network access to download URLs that your web filter may not have allowlisted. When any of these conditions fails, the update silently dies. No error message. No notification to IT. The user just keeps running the old version until something breaks.

The result is version drift. Machine A runs version X, machine B runs version Y, and machine C never updated past the initial install because it was offline during the one window when the updater had enough permissions to work. Your security team thinks everyone is current. They are wrong.

Cowork features, MCP server improvements, and security patches all arrive through these updates. There is no separate delivery channel. Either you manage the update pipeline or you accept fragmentation as a permanent condition.

The seven policy keys that control everything

Anthropic provides seven enterprise policy keys that govern Claude Desktop behavior at the machine level. On Windows, they live at HKLM:\SOFTWARE\Policies\Claude and deploy through Intune, GPO, or any configuration management tool that writes registry values. On macOS, the same keys sit under the com.anthropic.claudefordesktop preference domain, delivered through MDM configuration profiles.

Two keys control the update pipeline directly.

disableAutoUpdates is a boolean, default false. Setting this to true is the single most important fleet management decision you will make. It stops the built-in updater from downloading or applying anything. Updates only happen when IT pushes them. This is the foundation.

autoUpdaterEnforcementHours is an integer between 1 and 72, defaulting to 72. When auto-updates are still enabled, this controls how many hours the app waits before force-restarting to apply a downloaded update. At the default of 72 hours, users get three days before the app restarts itself mid-conversation. Useful if you keep auto-updates on for a pilot group. Irrelevant once you disable auto-updates entirely.

The remaining five keys control feature access, and you should configure them all before rollout:

isDesktopExtensionEnabled (boolean, default true) controls whether Claude Desktop Extensions can run. Disable this if your security team has not evaluated the extension model yet.

isDesktopExtensionDirectoryEnabled (boolean, default true) controls access to the extension directory. Even with extensions enabled, you can prevent users from browsing and installing extensions from the public directory.

isLocalDevMcpEnabled (boolean, default true) controls local MCP server connections. Disabling this prevents developers from running custom MCP integrations, which might be appropriate for non-developer seats.

isClaudeCodeForDesktopEnabled (boolean, default true) controls the Claude Code tab inside Claude Desktop. Organizations that want conversational AI but not code generation for all users toggle this off for specific groups.

secureVmFeaturesEnabled (boolean, default true) controls Cowork VM capabilities. Cowork requires Virtual Machine Platform to be enabled on Windows, which is a separate infrastructure decision your virtualization team needs to approve.

Push all seven keys through your configuration management before users get access. Retroactive policy deployment works, but it creates a window where the defaults apply and users form habits around features you planned to disable.

Windows fleet updates through Intune

The MSIX packaging model that Anthropic uses for enterprise Windows is well-suited for ongoing updates. MSIX handles in-place upgrades cleanly. A newer package supersedes the older one without requiring uninstallation first.

The update workflow runs like this. Download the current MSIX from Anthropic’s distribution endpoint. Both x64 and ARM64 packages are available at stable redirect URLs. Upload the new MSIX to Intune as a Line of Business app. Configure supersedence so the new version replaces the previous one. Assign to the same device groups. Intune handles the rollout.

Testing before deployment matters here. Assign the new MSIX to a pilot group first. Give that group a few days of real usage. Watch for MCP connection failures, extension compatibility problems, or behavioral changes that affect workflows. Then roll to the broader fleet. The weekly release cadence means your pilot cycle must be tight. Three to five days, not two weeks.

One complication catches teams off guard: the Squirrel-to-MSIX migration. Older Claude Desktop installations used a different installer framework that places files per-user into the user’s local app data directory. MSIX installs per-machine into Program Files. These are fundamentally different models and they do not coexist cleanly. If machines in your fleet received Claude Desktop through an older installer before IT standardized on MSIX, you need to uninstall the old version before deploying the MSIX package. Running both creates conflicts in file associations, auto-start behavior, and process management.

A detection script that checks for the older installation path saves time. If it exists, trigger an uninstall before deploying the MSIX. This prevents the ghost-process and duplicate-icon problems that frustrate users and generate tickets.

AppLocker environments need one more step. The MSIX package is signed by Anthropic, but your AppLocker policy may not have the publisher allowlisted. Add the publisher rule before deployment. Otherwise, your machines will refuse to launch the app even after a successful install, and the error message will not clearly explain why.

macOS fleet updates through MDM

macOS deployment uses a universal PKG installer covering both Intel and Apple Silicon. Upload the PKG to your MDM platform. Jamf, Kandji, and Intune for Mac all handle PKG distribution natively. The PKG manages upgrade paths automatically when deployed to the same installation location.

Installation path matters more than most teams realize. Installing to ~/Applications (the user-level folder) means the user has write access and can trigger updates independently. Installing to /Applications (the system-level folder) requires admin privileges for any modification, including updates.

For managed fleets, /Applications plus disableAutoUpdates via MDM profile gives IT complete control. Users cannot update on their own. Updates arrive only when MDM pushes a new PKG. This is the recommended configuration for any organization that needs version consistency.

The policy keys deploy through MDM configuration profiles targeting the com.anthropic.claudefordesktop preference domain. The same seven keys apply. Create a profile with the keys you want to enforce, assign it to your device groups, and the preferences activate at next login. Most MDM platforms push these profiles without requiring a device restart.

Watch for one edge case: a user who installed Claude Desktop to ~/Applications before IT set up managed deployment. You end up with two copies. The user-level version may still auto-update and launch at login, conflicting with the managed version in /Applications. Detection scripts that check for ~/Applications/Claude.app help you find and clean up rogue installations before they cause confusion.

Catching version drift before it catches you

Everything above is prevention. You also need detection. Version drift is silent. Nobody files a ticket saying “my software is on the wrong version.” They file tickets saying “this thing stopped working” or “my colleague can do something I cannot,” and your support team spends hours before someone thinks to check version numbers.

On Windows, Intune’s device inventory tracks installed MSIX packages and their versions. Build a compliance policy that flags machines where the Claude Desktop version does not match your current approved release. Intune can generate reports and trigger remediation actions when non-compliance is detected.

On macOS, Jamf and Kandji offer equivalent inventory capabilities. Smart groups filtered by application version give you a real-time view of your fleet’s version distribution.

A practical update cadence for most organizations: check for new Claude Desktop releases every two weeks. Download, test with your pilot group for a few days, then push to the broader fleet. This keeps you reasonably current without the operational burden of processing every weekly release. Security patches should move through the pipeline immediately when announced. Routine feature updates can follow the standard cycle.

The organizations that do this well treat Claude Desktop updates the way they treat browser updates or OS patches. Owned by IT. Governed by policy. Tested before deployment. Monitored for drift. The ones that struggle treated initial deployment as the finish line and assumed the auto-updater would handle everything after that. It will not.