Your developers have probably already found Claude Code. The question is whether your IT team has.
That gap, between when a tool enters the workflow and when the organization actually governs it, is where most enterprise AI problems quietly begin. This blog is for the IT administrators and engineering leaders who want to close it before it becomes a problem.
By the end of this blog, you’ll know exactly what Claude Code is, what it can do inside your environment, what happens when it runs without enterprise controls, and how to deploy, configure, and manage it across your fleet through Scalefusion.
What is Claude Code?
Claude Code is Anthropic’s agentic coding tool. It lives in the terminal, reads your codebase, and executes development tasks through natural language.
That last word matters: executes. Not suggests. Not previews. Claude Code reads files across your project, writes and modifies code across multiple files simultaneously, runs tests, handles failures, iterates, and commits results. When a developer tells it to refactor a module, add authentication to an endpoint, or fix a failing CI pipeline, it works through the task the same way a developer would, except it doesn’t need someone watching every step.
Stripe deployed Claude Code across 1,370 engineers of all levels. One team completed a 10,000-line Scala-to-Java migration in four days, work estimated at ten engineer-weeks. That’s not a productivity boost. That’s a category shift in what engineering teams can ship.
Claude Code runs in the terminal and integrates natively with VS Code, Cursor, Windsurf, and JetBrains IDEs. It works with GitHub and GitLab, can monitor CI pipelines, auto-fix failures, and raise pull requests. Anthropic reports that roughly 27% of Claude Code-assisted tasks were work that would not have been attempted without the tool at all. Engineers aren’t just moving faster. They’re taking on work they previously wouldn’t.
What Claude Code can do inside your environment
Before getting into configuration, it’s worth being specific about what Claude Code actually does on a machine, because this is where the enterprise conversation has to start.
Claude Code reads your entire codebase in context. It executes shell commands, edits files, makes network requests, and calls external services. It supports Model Context Protocol (MCP) servers, which means it can connect to your internal databases, APIs, documentation systems, and monitoring tools. In auto mode, actions that fall within a safety classifier’s threshold are executed without waiting for individual human confirmation.
None of that is a problem when it’s configured correctly. All of it is a problem when it isn’t.
A developer running Claude Code with default settings is running it with their own user-level permissions. It can read environment files, SSH keys, and credentials in their working directory. It sends code context to Anthropic’s servers for processing. Without org-bound authentication, a developer can use a personal account. Without model restrictions, it will use whichever model is available. Without permission controls, the –dangerously-skip-permissions flag is accessible, removing confirmation prompts on shell commands and file edits entirely.
For a solo developer on a personal project, none of that matters. For a developer with access to production infrastructure at an enterprise, all of it does.
What happens when Claude Code runs unmanaged at scale
Most enterprises that have a Claude Code problem don’t know they have one yet.
The adoption pattern is consistent: a few developers try it, productivity goes up noticeably, word spreads, and suddenly thirty engineers across three teams are running it under their own configurations. Some are authenticated with personal accounts. Some have connected local MCP servers IT never reviewed. Some are running with permission bypass enabled because it’s faster. The AI tool that started as a pilot is now embedded in the development workflow, and there’s no visibility into any of it.
The specific risks in a regulated environment are not abstract. Developers on personal accounts mean proprietary code sent to Anthropic under consumer terms, which have different data handling defaults than enterprise agreements. Unvetted MCP servers mean tool integrations connecting to Claude that no one in IT approved. Uncontrolled model access means some teams running Opus while cost controls assume Sonnet. And with no org-bound authentication, personnel changes don’t automatically close access.
None of this requires malicious intent. It’s just what organic adoption without governance looks like.
How Anthropic built the enterprise policy layer
Here’s the part most IT teams outside of security-focused enterprises haven’t discovered yet.
Anthropic built a proper enterprise configuration layer for both Claude Code and Claude for Desktop. Both products support MDM-deployed managed preferences through Apple’s standard .mobileconfig mechanism on macOS, and equivalent Windows registry policies via Group Policy or Intune on managed Windows devices.
When a configuration profile is pushed through Scalefusion, those settings sit at the highest precedence level in Claude Code’s settings hierarchy. No other settings level can override them, including command line arguments. Not through the app, not through CLI flags, not through local config files.
The key policy controls for Claude Code:
availableModelsrestricts which models developers can select via /model or –model. Set it to [“haiku”, “sonnet”] and Opus is simply not available on that device, regardless of the account’s entitlements.forceLoginOrgUUIDrequires that the authenticated account belongs to your specific Claude organization. A personal account won’t authenticate. A developer who leaves the company loses access automatically when their org membership is revoked.forceLoginMethod: "claudeai"locks authentication to Claude.ai accounts only, blocking Anthropic Console or API key-based login.permissions.disableBypassPermissionsMode: "disable"removes the –dangerously-skip-permissions CLI flag entirely. Developers cannot skip human confirmation on shell commands and file edits, even if they know the flag exists.disableAutoMode: "disable"removes auto mode from the permission cycle, ensuring a human is in the loop for every action Claude Code takes on the system.companyAnnouncementsdisplays a custom message to developers at Claude Code startup, useful for surfacing internal guidelines, approved MCP server lists, or compliance reminders.
For Claude for Desktop, the equivalent controls cover MCP server connections (isLocalDevMcpEnabled), extension signature verification (isDesktopExtensionSignatureRequired), the Claude Code terminal interface within the desktop app (isClaudeCodeForDesktopEnabled), Cowork/computer use features (secureVmFeaturesEnabled), and update management (disableAutoUpdates, autoUpdaterEnforcementHours).
Deploying Claude Code through Scalefusion, step by step
Both Claude Code and Claude for Desktop are deployed through Scalefusion’s Custom Settings feature within macOS Device Profiles. The same approach applies across your managed Mac fleet from a single dashboard. For Windows devices, equivalent policies are deployed through Scalefusion’s Windows MDM profile configuration.
Step 1: Sign in to the Scalefusion Dashboard and navigate to Device Profiles and Policies > Apple Configurations.
Step 2: Select an existing Apple Configuration and click Edit, or create a new one for this deployment.
Step 3: In the Config sidebar, navigate to macOS and select ‘Custom Configuration’.
Step 4: Paste your configuration payload directly into the Custom Settings editor or use the Import Files button to upload it as an XML file.
Step 5: Click Validate. A green checkmark confirms the payload is correctly formed.
Step 6: Keep Send Payload on User Channel toggled OFF. These payloads are intended to apply at the device level, enforcing configuration for all users on the machine.
Step 7: Click Save. The configuration pushes to every managed device associated with this profile.
A complete security-first payload for Claude for Desktop, covering extensions, MCP connections, update management, and Cowork:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key>
<string>com.anthropic.claudefordesktop</string>
<key>PayloadIdentifier</key>
<string>com.yourorg.claudefordesktop.REPLACE-WITH-UUID</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-UUID</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>disableAutoUpdates</key>
<true/>
<key>autoUpdaterEnforcementHours</key>
<integer>1</integer>
<key>isClaudeCodeForDesktopEnabled</key>
<false/>
<key>isDesktopExtensionEnabled</key>
<false/>
<key>isDesktopExtensionSignatureRequired</key>
<true/>
<key>isLocalDevMcpEnabled</key>
<false/>
<key>secureVmFeaturesEnabled</key>
<false/>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>Claude for Desktop – Managed</string>
<key>PayloadIdentifier</key>
<string>com.yourorg.claudefordesktop.profile</string>
<key>PayloadOrganization</key>
<string>Your Organization</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-PROFILE-UUID</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>To verify the deployment on a managed device, open Claude Code in the terminal and run /status. The output will show “Enterprise managed settings (plist)” under the Setting sources section, confirming that managed preferences are active and listing which settings are being enforced.
Note: Both the Claude for Desktop and Claude Code payloads can be included in the same Custom Settings editor. Ensure each has a unique PayloadIdentifier and PayloadUUID.
Configuring profiles by team
One payload for your entire fleet is not the right approach, and this is where Scalefusion’s Device Groups earn their place.
A developer with production infrastructure access needs a different Claude Code configuration than a product manager, a QA engineer, or a compliance analyst. Uniform policy means you’re either giving everyone too much or locking everyone down too far. Neither serves the business.
The practical approach is three profiles applied to three device groups managed from the same Scalefusion dashboard:
- Engineering profile: Broader model access (Sonnet and Opus in
availableModels), MCP connections permitted for vetted internal integrations, extensions allowed withisDesktopExtensionSignatureRequired: true, so only verified extensions load. - General staff profile: Claude for Desktop access with extensions disabled, no local MCP connections, updates on IT-controlled rollout, Claude Code terminal interface disabled.
- Regulated or compliance-sensitive profile: Haiku only via
availableModels, permission bypass and auto mode both disabled, org-bound authentication enforced viaforceLoginOrgUUID, MCP connections off.
When a new engineer joins the team, they get provisioned into the engineering device group. Claude Code lands on their machine already org-authenticated, already within policy, already configured for their role. No manual setup step. No onboarding doc, they might not read.
When someone moves teams or leaves the company, their device group changes or their org membership is revoked. Access follows the person’s role, not their memory of what they’re supposed to have.
The right time to get this right
Claude Code is not a tool that will be evaluated, approved, and then rolled out on a schedule. It is already on your devices. Developers who’ve made it part of their workflow are not going to stop using it because an IT policy arrives late.
The organizations that will handle this well are the ones that meet developers where they are: acknowledging that Claude Code is genuinely useful, keeping it accessible, and putting the governance infrastructure in place that lets it run within appropriate boundaries.
Scalefusion gives IT the visibility and enforcement layer to make that real. Developers keep the tool. The organization gets the deployment it designed.
Ready to manage Claude Code across your fleet?
Explore Scalefusion’s macOS and Windows MDM capabilities.
FAQs
Does Claude Code run on Windows?
Yes. Claude Code supports Windows, and equivalent managed settings are deployable via Windows registry policies through Group Policy or Microsoft Intune. Scalefusion’s Windows MDM profile management covers this deployment path.
Can I include both Claude for Desktop and Claude Code payloads in the same Scalefusion profile?
Yes. Both payloads can be combined in the same Custom Settings editor. Each payload needs a unique PayloadIdentifier and PayloadUUID to be processed correctly.
What happens if a developer tries to override a managed setting?
The setting does not appear as an option. It is not greyed out. For settings like --dangerously-skip-permissions on Claude Code, the flag is removed from the CLI entirely. There is nothing to override.
Does this work on BYOD devices?
Endpoint-managed settings via MDM require device enrollment. For unmanaged or BYOD devices, Anthropic also offers server-managed settings configured through the Claude.ai Admin console (requires Claude for Teams v2.1.38 or Claude for Enterprise v2.1.30 and later). Note that server-managed settings are client-side and can be tampered with by users with administrator access. For stronger enforcement guarantees, MDM-deployed endpoint settings are the recommended approach on managed devices.
Can I restrict which models individual teams can access?
Yes. The availableModels key accepts an array of model names and restricts the /model command and –model flag to only the listed models. Applied per Device Profile, this means different teams can have different model access without any reliance on users self-regulating.
Will managed settings slow down developers or get in their way?
Configured correctly, no. Managed settings remove options that fall outside policy. They don’t add friction to the options that remain. A developer on a profile with Sonnet access, approved MCP connections, and extensions permitted experiences Claude Code normally. The configuration is invisible unless they try to do something outside the defined boundary.
How do I verify that settings deployed correctly across the fleet?
Run /status in the Claude Code CLI on any managed device. The output lists active settings sources. Managed preferences show as “Enterprise managed settings (plist)” confirming the profile is active. For Claude for Desktop, restricted features simply don’t appear in the interface.
