How to deploy Claude Desktop and Cowork on locked-down enterprise Windows

I sat with an IT admin who tried to install Claude Desktop three times inside one hour. Three failures. Three completely different error messages.

This was a mid-size company running Intune the way a company should. Policies locked down, endpoints managed, security team actually paying attention. They’d heard about Claude Cowork and wanted to try it. Reasonable request.

First attempt: ClaudeSetup.exe downloaded, started, then stopped cold demanding Developer Mode. Second attempt: the IT admin elevated to an admin account, which introduced a completely different bug. Third attempt: they got through the install but the verification email never arrived. The corporate gateway ate it without any notice.

An hour gone.

The team was skeptical about whether this tool was enterprise-ready, and honestly, that’s a completely fair reaction. The frustrating part is that all three failures had known solutions. The installer just handles enterprise environments badly.

Enabling Developer Mode - which is what every forum post recommends - is the wrong answer for any company that takes security seriously. It’s the quick fix that creates a much bigger problem.

The deployment path that actually works doesn’t require Developer Mode. No weakened security posture. No registry changes that’ll make your security team lose sleep.

If your developers are already hitting Windows tooling friction, broken AI tool deployment just piles on.

Why the standard installer fails on enterprise Windows

ClaudeSetup.exe isn’t a typical MSI installer. It downloads and registers an MSIX package, which is Microsoft’s modern app packaging format. MSIX packages are cryptographically signed and sandboxed - genuinely more secure than traditional installers. The problem isn’t the package. It’s how the installer bootstraps it.

The Developer Mode trap. On enterprise Windows, a Group Policy called AllowAllTrustedApps controls whether MSIX sideloading is permitted. When that policy is restricted (and it should be on managed devices), the installer throws an error asking you to enable Developer Mode. Forum posts treat this like a simple toggle. It isn’t. GitHub discussions document this pattern repeatedly: enterprise users hitting the Developer Mode wall on machines IT has locked down correctly.

Enabling Developer Mode opens a long list of capabilities that have nothing to do with installing Claude. Microsoft’s own documentation lists what switches on: sideloading of apps from any source, device discovery and pairing, and various developer debugging capabilities. Your security director is right to push back. It violates CIS benchmarks for Windows hardening, conflicts with NIST 800-53 configuration management controls, and if your company holds ISO 27001 certification, enabling Developer Mode across your fleet creates audit findings under Annex A.

The split-account registration bug. Enterprise Windows environments typically use a split-account model: users work with standard privileges, IT operations run through a separate admin account with UAC elevation. When the installer runs under the admin context but the user session belongs to a different account, the MSIX package registers under the wrong profile. The app installs. Appears to work. Then the claude:// protocol handler breaks because it’s pointing at the admin profile instead of the actual user. A closed bug now, but it burned real hours before anyone documented it properly.

The email verification wall. After installation, Claude Desktop requires email verification. Personal Gmail accounts? Fine. Corporate email behind Mimecast, Proofpoint, or Barracuda? The anthropic.com verification emails get silently quarantined or delayed. No error message. The user sits there waiting for an email that never comes.

Each failure takes 15 to 30 minutes to diagnose on its own. Together, they can burn an entire afternoon and leave a bad first impression that’s hard to shake.

Three deployment methods that skip the installer

Skip ClaudeSetup.exe entirely. Deploy the signed MSIX package directly instead. Anthropic provides deployment documentation for exactly this scenario. Three paths, ranging from fully managed to quick-and-dirty.

Option A: Intune LOB app

Cleanest approach for any organization already running Intune. Zero endpoint policy changes. No Developer Mode. No GPO modifications.

Steps, adapted from Microsoft’s Intune LOB documentation:

1. Download the MSIX package from Anthropic’s deployment page (the direct .msix file, not ClaudeSetup.exe)
2. Open Intune admin center, go to Apps > Windows > Add
3. Select Line-of-business app as the app type
4. Upload the MSIX package
5. Set Install behavior to Device context - this is the critical step. Device context sidesteps the split-account bug entirely because the package registers machine-wide rather than per-user
6. Assign to a device group, not a user group
7. Deploy

That’s it. The MSIX is signed by Anthropic, so it installs through the normal trusted app pipeline. No sideloading required. No Developer Mode required. The whole setup takes about 15 minutes for someone who has done LOB deployments before.

Option B: PowerShell provisioned install

For quick deployment to a handful of machines, or for environments without Intune:

Add-AppxProvisionedPackage -Online -PackagePath "Claude.msix" -SkipLicense -Regions "all"

This provisions the package machine-wide. Every user who signs into that machine gets Claude Desktop without any additional steps. Must run from an elevated PowerShell session.

Downside: no centralized management, no automatic updates through Intune, and you need physical or remote access to each machine.

Option C: Win32 app via Intune

For organizations that prefer the Win32 app management pipeline over native MSIX handling, wrap the package using Microsoft’s IntuneWinAppUtil:

1. Wrap the MSIX into an .intunewin package
2. Upload as a Win32 app in Intune
3. Use the PowerShell provisioning command as the install command
4. Set detection rule to check for the AppX package presence

This gives you the full Win32 app management toolkit - requirement rules, dependency chains, supersedence - at the cost of slightly more setup complexity.

Cowork needs one Windows feature

If you want Cowork (Claude’s agentic computer-use capability), machines need the Virtual Machine Platform feature enabled:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart

Standard Windows feature. The same one WSL2 and Windows Sandbox depend on. Not Developer Mode. Far less permissive than Hyper-V, and already enabled on many enterprise machines. Your security team should have no objections.

The email verification fix

Two options. First: whitelist anthropic.com in your email security gateway. Add the domain to your allowlist in Mimecast, Proofpoint, or whatever you run. Two minutes. Permanent fix.

Second: if you’re on the Enterprise plan, configure SAML SSO. This bypasses email verification entirely because authentication flows through your identity provider. Cleaner, more auditable, and one less failure mode.

What your CISO needs to know before signing off

Claude Desktop deploys fine with the methods above. Cowork is a different conversation, and I think it’s worth being direct about the gaps before you roll it out.

No audit logs for Cowork activity. This is the big one. Anthropic explicitly states that Cowork activity isn’t captured in Audit Logs, the Compliance API, or data exports. If your organization operates under SOC 2, HIPAA, or any framework that requires activity logging for tools that access company data, this is currently a non-starter for regulated workloads. It might be fine for your marketing team. It’s probably not fine for your finance team handling sensitive data. You can read more about compliance considerations for Claude tools for additional context.

Prompt injection file exfiltration. Earlier this year, researchers showed that hidden text in documents - 1-point white-on-white text invisible to humans - could instruct Cowork to upload files to an attacker’s Anthropic account. The Register covered the disclosure and The Decoder published additional technical details. The vulnerability was reported through HackerOne in October 2025 and initially dismissed. Anthropic has since implemented mitigations, but the fundamental attack surface remains: an AI agent that can read files and take actions based on hidden instructions in those files. Your security team needs to understand this before deployment.

Org-wide toggle only. Cowork is enabled or disabled for the entire organization. No per-user or per-role granularity through the admin console. If you want selective rollout, you either work directly with Anthropic’s sales team for custom configuration, or handle it at the endpoint level by controlling VirtualMachinePlatform feature deployment.

Web search bypasses egress restrictions. When Cowork performs web searches, those requests don’t pass through your corporate proxy or egress filtering. If you rely on network-level controls to prevent data exfiltration or enforce acceptable use policies, Cowork’s web search needs to be disabled separately. Anthropic’s safety guide covers how to restrict this.

Is that a realistic concern for most teams? Depends entirely on your industry. For healthcare, finance, or legal, I’d treat it as a hard requirement to address before any rollout.

It’s also worth noting that GitHub Copilot deploys as a VS Code extension - no Developer Mode, no MSIX complications, no special Windows requirements. Cursor installs as a standard desktop application. Claude Desktop’s deployment is harder than its competitors right now. That doesn’t mean it’s not worth deploying. It means your IT team needs to plan for it differently.

Practical mitigations for day one:

• Restrict Cowork to dedicated working folders, not entire drives
• Disable web search until your security team evaluates the egress implications
• Pilot on non-sensitive workloads first
• Wait for audit log support before deploying to teams handling regulated data
• Monitor Anthropic’s security advisories through their support channels

Policy configuration for fleet control

Once Claude Desktop is deployed, you need to control it at scale. Anthropic’s enterprise configuration guide documents a registry-based policy system. These keys override in-app settings, so users can’t change them.

The registry path is HKLM:\SOFTWARE\Policies\Claude. Here are the policies that matter most:

Deploy through Intune configuration profiles using OMA-URI settings, or through traditional GPO Administrative Templates if you’re still on on-prem Active Directory.

Two things worth noting for fleet deployment. If you run AppLocker or Windows Defender Application Control, the MSIX package is signed but may need an explicit allowlist entry depending on how tight your policies are. Test in audit mode before enforcing. And disableAutoUpdates matters for change management: you don’t want 500 machines auto-updating to a new Claude version on a random Tuesday.

If you’re already scaling AI tools across your enterprise, this registry approach fits neatly into existing configuration management workflows. Consistent policy enforcement becomes especially important if your developers are using Claude for daily coding work.

Managing updates without losing control

MSIX packages auto-update without admin elevation by design. This is standard MSIX behavior - signed packages update in user context without UAC prompts. For IT teams used to controlling every binary on managed machines, this feels wrong. It is actually the right default for most deployments.

The practical question is whether to let auto-updates run or lock them down with disableAutoUpdates. Both approaches have tradeoffs.

Letting auto-updates run means users always have the latest features. Claude Desktop ships weekly updates, and new capabilities like Cowork require minimum versions to function. If your fleet falls behind, users hit confusing errors - features that should work simply do not appear, with no clear explanation why. Keeping auto-updates on avoids that support burden entirely.

Blocking auto-updates gives IT full control over what version runs on managed machines. The disableAutoUpdates registry policy (DWORD, set to 1) prevents Claude Desktop from updating itself. IT then downloads the latest MSIX and pushes it through Intune on a controlled schedule. Clean change management, predictable fleet state, no surprises.

The middle ground is autoUpdaterEnforcementHours. This policy (Integer, 1-72, default 72) forces a restart to apply pending updates within your chosen window. Users get auto-updates, but IT sets the maximum delay before those updates take effect. Anthropic documents both policies in their enterprise configuration guide.

A reasonable cadence for most organizations: weekly pushes during the first 90 days of deployment (while the product is new and changing fast), then relaxing to monthly or quarterly once the deployment stabilizes. Weekly is aggressive, but Claude Desktop is still in rapid development. Missing two or three weeks of updates can leave users unable to access features their colleagues are using.

There is a real risk of NOT updating. Issue #28998 documents a case where users on older Squirrel-based installs see a “Check for Updates” button that falsely reports they are running the latest version. They are not. The only fix is a manual uninstall and reinstall of the MSIX package. Related: issue #25162 confirms there is no automatic upgrade path from the older Squirrel installer to the current MSIX format. If any machines in your fleet had Claude Desktop installed before the MSIX transition, those installs will silently fail to update. A clean uninstall/reinstall is the only path forward.

For organizations planning to use MCP (Model Context Protocol) integrations, be aware of issue #31864. Auto-updates can silently break MCP server configurations by introducing extension-based management that conflicts with legacy mcpServers JSON config. If you have MCP integrations running, test updates in a staging environment before pushing to production machines.

For IT teams that want to automate the update cycle through Intune, dave-jonas/ClaudeDesktop is a community-maintained repository with ready-made PowerShell scripts for install, detect, and uninstall - plus a registry policy script that deploys all the enterprise configuration settings via Microsoft Graph. It is not official Anthropic tooling, but it saves real hours compared to building your own Intune package from scratch.

The deployment sequence that actually works

What I’d recommend, based on watching this play out across real enterprise environments, follows a three-week sequence.

Week one: Claude Desktop only, no Cowork. Deploy via Intune LOB with secureVmFeaturesEnabled set to 0. Target 5 to 10 pilot machines across different user profiles - developers, analysts, executives. Document every issue. Your goal is a clean Intune package that works on first deployment.

Week two: expand and stabilize. Roll out to a broader pilot group. Resolve email verification issues by whitelisting anthropic.com or configuring SAML SSO. Lock down policies via the registry path. Validate that auto-update behavior matches your change management process.

Week three: security review for Cowork. If Cowork is on your roadmap, this is when your security team evaluates the gaps documented above. Enable VirtualMachinePlatform on pilot machines. Test with non-sensitive workloads. Decide whether the audit log gap is acceptable for your risk profile.

The conversation with your CEO or CIO needs to land on one thing: “This takes a different deployment path than most software. IT has it handled. Give us a week, not an hour.” The common mistake is treating it like a consumer app install. It’s not. It’s enterprise software that needs enterprise deployment.

Once the IT team knew the right approach, they deployed via Intune in under an hour. The three failures earlier weren’t really about Claude being hard to deploy. They were about not knowing the workaround for a broken installer flow.

What Anthropic should fix. The installer should detect enterprise environments and redirect to deployment documentation instead of demanding Developer Mode. The split-account MSIX bug should have been caught in QA. Error messages should tell IT admins what to do, not leave them guessing. Solvable problems, all of them.

Every enterprise tool worth deploying had an awkward early phase. Slack had proxy issues. Zoom had firewall problems. Teams needed Azure AD configuration that wasn’t documented for the first year. The deployment friction is temporary. The capability of having an AI agent that can run projects alongside your team is not going away. Get the deployment right once, and you won’t think about it again.