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

I watched someone try to install Claude Desktop three times in one hour. Failed every time.

This was at a mid-size company with IT locked down by Intune the way it should be. They had heard about Claude Cowork and wanted to try it. Reasonable request. Should have been straightforward.

First attempt: ClaudeSetup.exe downloaded fine, started running, then hit a wall demanding Developer Mode. Second attempt: the IT admin tried running the installer under an elevated admin account, which introduced a different bug. Third attempt: they got through the install but the email verification link never arrived because the corporate email firewall silently ate it.

Three failures. One hour gone. Now skeptical about whether this tool is enterprise-ready.

The thing is - all three problems have known solutions. The standard installer just handles enterprise environments badly. And enabling Developer Mode, which is what every forum post suggests, is the wrong answer for any company that takes security seriously.

Here is the deployment path that works. No Developer Mode. No weakened security posture. No registry hacks that will make your security team lose sleep.

If your developers are already hitting Windows tooling friction, broken AI tool deployment just adds insult to injury.

Why the standard installer fails on enterprise Windows

ClaudeSetup.exe is not 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 is not the package itself. It is how the installer bootstraps it.

The Developer Mode trap. On enterprise Windows machines, a Group Policy called AllowAllTrustedApps controls whether MSIX sideloading is permitted. When this policy is restricted - which it should be on managed devices - the installer throws an error asking you to enable Developer Mode. Users and forum posts treat this as a simple toggle. It is not. GitHub issue discussions document this pattern repeatedly: enterprise users hitting the Developer Mode wall on machines where IT has locked things down correctly.

Enabling Developer Mode on an enterprise machine opens a long list of capabilities that have nothing to do with installing Claude. Microsoft’s own documentation spells out what switches on: SSH server services, sideloading of unsigned apps, device discovery protocols, USB debugging interfaces, and loosened PowerShell execution policies. Your IT security director is right to push back on this. It violates CIS benchmarks for Windows hardening. It conflicts with NIST 800-53 configuration management controls. 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, and IT operations happen through a separate admin account with UAC elevation. When the installer runs under the admin context but the user session is under 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 is pointing at the admin profile instead of the actual user. This is a closed bug now, but it burned real hours for IT teams before it was documented.

The email verification wall. After installation, Claude Desktop requires email verification. For personal Gmail accounts, this works fine. For corporate email behind Mimecast, Proofpoint, or Barracuda gateways, the anthropic.com verification emails get silently quarantined or delayed. There is no error message. The user just sits there waiting for an email that never comes, assuming the install broke.

Each of these failures individually takes 15-30 minutes to diagnose. Together, they can burn an entire afternoon and leave a bad first impression that is hard to recover from.

Three deployment methods that bypass the installer

The fix is simple: skip ClaudeSetup.exe entirely and deploy the signed MSIX package directly. Anthropic provides deployment documentation for exactly this scenario. Here are three paths, ranging from fully managed to quick-and-dirty.

Option A: Intune LOB app (recommended)

This is the cleanest approach for any organization already running Intune. It requires zero endpoint policy changes. No Developer Mode. No GPO modifications.

The 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, navigate 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 critical. 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 is it. The MSIX is properly signed by Anthropic, so it installs through the normal trusted app pipeline. No sideloading required. No Developer Mode required. The whole Intune package 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. It persists across new user logins, meaning every user who signs into that machine gets Claude Desktop without any additional steps. Must run from an elevated PowerShell session.

The 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, you can 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.

Post-install: Cowork requires 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

This is a standard Windows feature. It is the same feature that WSL2 and Windows Sandbox depend on. It is NOT Developer Mode. Your security team should have no objections - this is far less permissive than Hyper-V and is already enabled on many enterprise machines.

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. Takes two minutes and solves the problem permanently.

Second: if you are 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 thing that can break.

What your CISO needs to know before signing off

I’m going to be honest here. Claude Desktop deploys fine with the methods above. Cowork raises legitimate security questions that deserve straight answers before you roll it out.

No audit logs for Cowork activity. This is the big one. Anthropic explicitly states that Cowork activity is not 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 is 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. In January 2026, researchers demonstrated 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 - an AI agent that can read files and take actions based on hidden instructions in documents - remains something your security team should understand.

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

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

Honest comparison. I think it is worth noting that GitHub Copilot deploys as a VS Code extension - no Developer Mode, no MSIX issues, no special Windows requirements. Cursor installs as a standard desktop application. Claude Desktop’s deployment is genuinely harder than its competitors right now. That does not mean it is 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

Enterprise policy configuration at scale

Once Claude Desktop is deployed, you need to control it. Anthropic provides a registry-based policy system documented in their enterprise configuration guide. These registry keys override in-app settings, so users cannot change them.

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

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

For teams that prefer file-based configuration over registry, Anthropic also supports a managed settings file at C:\ProgramData\ClaudeCode\managed-settings.json. Same effect, different mechanism. Choose whichever fits your configuration management pipeline.

Two additional considerations for fleet deployment. First, if you run AppLocker or Windows Defender Application Control (WDAC), 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. Second, the disableAutoUpdates key is important for change management - you probably do not want 500 machines auto-updating to a new Claude version on a random Tuesday.

These policies give IT the same level of control they have over any other managed application. If you are already scaling AI tools across your enterprise, this registry approach fits neatly into existing configuration management workflows. And if your developers are using Claude for daily coding work, consistent policy enforcement becomes even more important.

The deployment sequence that works

Here is what I’d recommend based on watching this play out in real enterprise environments.

Week one: Claude Desktop only, no Cowork. Deploy via Intune LOB with secureVmFeaturesEnabled set to 0. Target 5-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 executive conversation. The CEO or CIO who wants Claude deployed needs to hear 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 is not. It is 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 were not 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 asking for Developer Mode. The split-account MSIX bug should have been caught in QA. The error messages should tell IT admins what to do, not leave them guessing. These are solvable problems, and I’d expect them to get better over time.

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