Set up Claude Code for your organisation

Rolling Claude Code out to a team is mostly a series of decisions taken in a sensible order. You pick where requests go and who pays, you decide how policy gets onto laptops, you decide what that policy says, and then you work out how you will see usage and satisfy your data and compliance people. This page walks those decisions one at a time and points to the detailed page for each.

The mechanism underneath all of it is managed settings: configuration that an administrator owns and that outranks anything a developer sets in their own user or project files. Managed settings can arrive from the Claude admin console, from your device management (MDM) tooling, or from a file on disk.

Note: Single sign-on, SCIM provisioning and assigning seats happen at the Claude account level, not inside Claude Code. Sort those out in your Claude organisation's admin settings before you start on the steps below.

The decisions at a glance

Step 1: choose an API provider

Every Claude Code session talks to Claude through one provider. The choice decides billing, how people log in, whose compliance controls you inherit and, importantly, which features are available.

Watch the feature gap. Several capabilities need a claude.ai account and do not work from a Console API key or cloud credentials alone: cloud sessions on the web, routines, Code Review, Remote Control and the Chrome extension. If you deploy through Bedrock, Vertex AI or Foundry, decide up front whether some developers also need Teams or Enterprise seats. The feature availability page lays this out per provider, and enterprise deployment options compares the providers in more depth.

Whatever you choose, the proxy and firewall rules in network configuration still apply. If you want one endpoint in front of several providers, or central request logging, look at the LLM gateway and Claude apps gateway pages.

Step 2: decide how policy reaches devices

Claude Code looks for managed policy in four places, in this order. The first one that has content wins for the managed tier.

Some practical guidance on picking:

• Server-managed needs no endpoint tooling at all. Claude Code pulls it at startup and refreshes it every hour. Delivery from the admin console requires Teams or Enterprise; Bedrock, Vertex AI and Foundry shops can get the same remote delivery by running a Claude apps gateway.
• Mixed estates (some people on claude.ai, some on a cloud provider) should use server-managed settings plus a file or OS-policy fallback, so nobody falls through the gaps.
• The plist and HKLM locations need admin rights to write, which makes them tamper-resistant and provider-agnostic.
• HKCU can be written by the user without elevation. Treat it as a convenient default, not as enforcement.
• WSL only reads /etc/claude-code by default. To make it inherit the Windows HKLM policy or the C:\Program Files\ClaudeCode file, set wslInheritsWindowsSettings: true in one of those admin-only Windows sources.

Managed values beat user and project values, with a handful of security-sensitive exceptions described on the settings page. Array settings such as permissions.allow and permissions.deny merge across every layer, so developers can add to your lists but cannot remove your entries. Three keys behave differently: fallbackModel, availableModels and modelPicker take the managed value outright rather than merging.

Claude Desktop and WSL sessions

On Windows, Claude Desktop can run Code sessions inside a WSL 2 distribution. Those sessions resolve policy through the Linux path, so Windows-only sources do not reach them unless wslInheritsWindowsSettings: true is deployed.

Desktop also switches WSL sessions off on machines it believes are organisation-managed (for instance when C:\Program Files\ClaudeCode\managed-settings.json exists). To permit them, create disableWslSessions under HKLM\SOFTWARE\Policies\Claude (note: the Desktop key, not ClaudeCode) with a REG_SZ value of false or a REG_DWORD of 0. This needs Claude Desktop v1.19367.0 or later and must be in HKLM; an HKCU value is ignored. You can leave your managed settings file in place. Desktop re-reads the policy whenever a WSL session starts, so no restart is needed.

If a machine still refuses, use Help > Troubleshooting > Show Logs in File Explorer in Desktop, open the copied main.log, and search for [wslPolicyGate] denying WSL session. The bracketed reason that follows, such as (cli-file-present), tells you which check failed.

One security note: processes inside the WSL 2 utility VM are invisible to Windows-side EDR sensors. If you need visibility there, run your vendor's Linux sensor inside the distribution. Claude Code's OpenTelemetry tool events are the same for WSL and native sessions.

Step 3: decide what to enforce

This is where most of the thinking goes. Each row below is a control surface and the keys that drive it.

A few of these deserve a sentence more:

• Login enforcement applies across the terminal, the VS Code extension, the Agent SDK, claude setup-token and /install-github-app. When it is set, sessions that authenticate with ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN or apiKeyHelper are blocked at startup. Cloud-provider sessions are unaffected unless one of those credentials is also present. The organisation check covers claude.ai logins, not Console or gateway sign-ins.
• minimumVersion versus requiredMinimumVersion: the first only stops auto-update from going below a floor. The second refuses to start a version outside the range at all.
• Permissions and sandboxing cover different layers. Denying WebFetch stops Claude's fetch tool, but if Bash is allowed then curl still reaches anything. Only the sandbox's network allowlist closes that hole at the OS level.

Controls that need no deployment

If your members sign in through claude.ai or the Anthropic API on an Enterprise plan, you can govern models from the organisation admin settings: disable individual models, set the default model new sessions start on, and cap effort per role. These are enforced server-side. They do not reach sessions on Bedrock, Vertex AI, Foundry or Claude Platform on AWS; there you use availableModels, model and maxEffortLevel in managed settings instead.

Cloud sessions have their own admin pages on claude.ai: organisation-shared cloud environments with network level, environment variables and setup scripts; a default environment choice; and a Git providers page.

Linked GitHub accounts

On Team and Enterprise, Organization settings > Git providers shows the GitHub organisations and personal accounts linked to your Claude organisation through the Claude GitHub App. Claude Code, Claude Tag and Claude Security share this list, and you need an admin role to see it.

Accounts get linked in two ways. An admin can click Connect (or Add organization) and install the app on a GitHub organisation, which needs someone who owns that GitHub organisation and is a Claude admin. Or a member connects their own GitHub account, for example while setting up cloud sessions, and any accounts they own that already have the app installed get linked. Rows marked Not linked come from your own GitHub sign-in.

Unlink from this workspace removes the link but leaves the app installed, so it will relink next time an owner connects. Uninstall the app on GitHub to stop that. Enterprise customers can audit these events through the Compliance API as github_app_installation_linked and github_app_installation_unlinked.

Step 4: set up usage visibility

On Teams and Enterprise, per-user spend lives in the spend report under analytics settings rather than on the dashboard. Cloud customers read spend from AWS Cost Explorer, GCP Billing or Azure Cost Management.

Step 5: review data handling

Anthropic does not train on your code or prompts on Team, Enterprise, API or cloud-provider plans. Your provider decides retention.

• Data usage covers what is collected and for how long.
• Zero data retention is available to qualified Enterprise accounts.
• HIPAA setup explains which local features are disabled or off by default for HIPAA-enabled organisations. Sessions routed through a gateway are not eligible for that configuration.
• Security covers the network model, encryption and audit trail.

If you need per-request audit logs or routing by data sensitivity, put a gateway between developers and the provider. A Claude apps gateway records each request against the user's IdP identity.

Verify and onboard

Once policy is deployed, ask a developer to run /status. On the Status tab, the Setting sources line should read Enterprise managed settings followed by the winning source in brackets. The managed settings page explains each label.

For onboarding, I point people at the quickstart and common workflows first. The commonest login fixes are:

1. /logout then /login to switch accounts.
2. claude update if the enterprise login option is missing.
3. Restart the terminal after updating.

"You haven't been added to your organization yet" means the person's seat does not include Claude Code. Fix it in the admin console.

Related

• Managed settings
• Server-managed settings
• Settings reference
• Enterprise deployment options
• Large codebases