Claude Code for a Company: Setup, Permissions and Review

Setting up Claude Code for a company is less about installing it, which takes one command, and more about deciding what it may do on your machines and in your repositories before developers start. The work is five decisions: how developers sign in and under which organization, which managed settings IT enforces, which permission rules and hooks apply in each repository, which MCP servers are allowed, and what review a change must pass before it merges. This guide covers each, using Anthropic's documentation as of October 2026.

Anthropic's Claude Code overview gives the native installer for macOS, Linux and WSL (a curl command piped to bash), a PowerShell command for Windows, plus Homebrew, WinGet and apt, dnf and apk packages. On native Windows, install Git for Windows so the Bash tool works. The Claude Desktop app includes Claude Code, so desktop app users need no separate install; a paid subscription is required. For who should be on Claude Code at all, and who belongs in Cowork, see Claude Cowork vs Claude Code.

How should developers sign in?

The Claude Code identity and access documentation lists the routes: a Claude Pro or Max subscription, a Claude Team or Enterprise account the admin invited, the Claude Console with API billing, or a cloud provider (Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry). For a company, work happens under the company's organization, not a developer's personal plan, which puts sessions under your settings, billing and data terms. Managed settings enforce it: forceLoginMethod and forceLoginOrgUUID restrict logins to a specific organization, and allowedProviders restricts which API providers a managed machine may use.

If you go the Console route, invite developers at the members page and give them the Claude Code role, which can only create Claude Code API keys, rather than Developer, which can create any key. Credentials are stored in the macOS Keychain, or in a credentials file in the user's .claude directory with owner-only permissions on Linux and Windows. For CI, claude setup-token creates a one-year OAuth token and needs a Pro, Max, Team or Enterprise account; treat it like any other secret.

What are managed settings, and where do they go?

Claude Code reads settings from four levels: the user's own file, the shared project file checked into the repository (.claude/settings.json), a project-local file that is not committed, and managed settings that the organization deploys. Per the settings documentation, managed settings sit above everything, including the command line: nothing in a developer's own files overrides a managed key. The managed settings page gives the delivery options:

A device-side file or MDM profile never reaches a cloud session at claude.ai/code, so if developers use cloud sessions you need server-managed settings too. And in a Cowork session on the desktop app, Claude Code does not fetch server-managed settings at all; it reads the device policy, so a Cowork fleet needs the device route. The keys most companies put in managed settings: permission deny rules, disableBypassPermissionsMode and disableAutoMode, allowManagedPermissionRulesOnly (ignore permission rules from user and project files), availableModels, the MCP allowlist, allowManagedHooksOnly, and the sandbox settings. Run /status in a session to see which managed source it is reading.

How do permission rules and allowlists work?

Claude Code starts interactive terminal and VS Code sessions in auto mode, where a separate classifier model reviews actions and blocks the ones it judges unsafe; the organization can turn that mode off. Manual mode starts read-only and asks before edits or commands; Accept Edits approves file edits and common filesystem commands in the working directory; Plan mode reads and runs read-only commands but does not edit, which is the mode to use before any large change. Bypass mode skips prompts and belongs only in a disposable container, which is why disableBypassPermissionsMode exists.

Rules live under permissions as allow, ask and deny lists, with syntax from the permissions documentation: Bash(npm run *) allows any npm script, Bash(git push *) in the ask list prompts before every push, Read(./.env) in the deny list stops Claude reading the environment file, WebFetch(domain:example.com) scopes web access to a host, and mcp__github__get_* allows only the read tools of a named MCP server. Deny beats allow and ask beats allow, so a broad deny such as Bash(aws *) cannot be carved open by a narrower allow, and a bare tool name in deny removes the tool from Claude entirely. Claude Code understands shell operators, so Bash(safe-cmd *) does not approve safe-cmd && something-else. A sensible company baseline: deny on secrets files and destructive commands in managed settings; project allowlists for the build, test and lint commands checked into each repository; ask on git push, package publishing and anything that touches production.

What should hooks enforce?

Hooks, per the hooks documentation, are shell commands, HTTP endpoints, MCP tool calls, prompts or subagents that run at points in Claude Code's lifecycle: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, ConfigChange and others. A PreToolUse hook can return a deny decision; exit code 2 blocks. Good company uses: a PostToolUse hook that runs the formatter and linter after every edit, a PreToolUse hook that filters test output down to failures to save tokens, a ConfigChange hook that logs or blocks settings changes, and a Stop hook that reminds the agent to run the test suite before declaring a task finished. Deploy the mandatory ones through managed settings with allowManagedHooksOnly so user and project hooks cannot replace them, and keep the list short. One caveat from Anthropic's own page: the hook filter is best-effort, so use the permission system, not a hook, for a hard allow or deny.

How should a company configure MCP?

MCP servers give Claude Code tools: your issue tracker, your database, your cloud console. The MCP documentation defines three scopes: local (the developer's own, current project only), project (a .mcp.json file in the repository root, shared through version control) and user (all of that developer's projects). Interactive sessions prompt before using project-scoped servers, but claude -p, the Agent SDK and cloud sessions load them without asking, so a .mcp.json committed by one developer becomes an unattended integration for everyone running automation on that repository.

Organization controls: allowedMcpServers filters the connectors Claude Code is given, deniedMcpServers blocks servers by name or URL pattern, disabledMcpjsonServers blocks a project server in every permission mode, managedMcpServers lets IT provide approved servers to every user, and allowManagedMcpServersOnly makes the managed allowlist the only one that counts. Use HTTP transport for remote servers (SSE is deprecated), prefer OAuth over fixed tokens, and heed Anthropic's warning that servers which fetch external content expose you to prompt injection. If you build your own servers, MCP server development covers how NetSys scopes and secures them, and how to review a Claude MCP connector is the checklist for third-party ones.

How do we keep secrets out of Claude Code?

1. Deny the files. Read(./.env), Read(./.env.*) and your key and certificate paths in the managed deny list, so the agent cannot read them even when asked.
2. Do not put credentials in .mcp.json. Claude Code reads credential variables such as ANTHROPIC_API_KEY as empty when expanding that file, so a project file cannot forward them to a remote server; use OAuth or a secrets manager instead.
3. Use the sandbox. Anthropic's security documentation lists a sandboxed Bash tool with filesystem and network isolation, a working-directory boundary prompt, no auto-approval of curl or wget, and command-injection detection; run Claude Code inside the sandbox or a dev container for anything sensitive.
4. Prefer cloud sessions for untrusted repositories. Each runs in an isolated VM, GitHub credentials never enter it, the GitHub proxy rejects branch deletions and non-branch pushes, and all operations are logged.
5. On Windows, do not enable WebDAV paths or allow network paths such as a double-backslash wildcard; Anthropic warns they can bypass the permission system.

What code review gates belong in front of Claude Code?

The same ones that belong in front of a new hire, enforced by your repository host rather than by the agent. Protected main branches, so Claude Code works on a branch and opens a pull request; a required human review on every pull request, with the reviewer reading the diff rather than the agent's summary; required status checks (tests, lint, a security scanner) that must pass before merge; and no force pushes. Claude Code also runs in GitHub Actions and GitLab CI/CD, which teams use for a first-pass review, and Anthropic's Claude Security plugin for Claude Code (in beta, for all Claude Code users) runs vulnerability checks with the models in the developer's own account. Neither replaces a person approving the merge.

Outside the session, OpenTelemetry metrics give you per-user usage and tool activity, and the Enterprise plan's Compliance API captures sessions; decide before the pilot what you will look at each month.

Pilot workflow

1. Choose the organization route (Team, Enterprise or Console) and lock sign-in to it with managed settings.
2. Deploy managed settings with the deny list, bypass mode disabled, the model list and the MCP allowlist; add server-managed settings if anyone uses cloud sessions.
3. Pick two repositories and three to five developers. Commit a .claude/settings.json with the build and test allowlist and a CLAUDE.md under 200 lines.
4. Turn on branch protection and required review if they are not already on.
5. Run for a month. Collect the permission prompts developers answered yes to every time; those become allowlist entries. Collect the ones that stopped something wrong; those stay.
6. Review usage and cost per developer (Claude Code costs for a team) and write the standard before widening.

What NetSys does for a Claude Code rollout

NetSys builds custom applications, dashboards and reporting roundups on Anthropic Claude and Microsoft tooling for client teams, and the same engineers set up Claude Code for companies: the sign-in route, managed settings through Intune or Jamf, repository permission files, hooks, the MCP allowlist and the review gates, delivered under our Claude Code consulting service with developer training included. Where the goal is an internal tool rather than a developer workflow, custom AI applications is the service.

Scope a Claude Code pilot with a NetSys engineer; bring the repositories and the team you have in mind.

Frequently asked questions

How do you install Claude Code on Windows?

Anthropic's overview gives a PowerShell installer command, a WinGet package and a CMD option, and recommends Git for Windows so the Bash tool works; otherwise Claude Code uses PowerShell. The Claude Desktop app for Windows (x64 and ARM64) also includes Claude Code. Run claude --version to see which version a machine has.

What is Claude Code auto mode?

The starting permission mode for interactive terminal and VS Code sessions, in which a separate classifier model reviews actions and blocks the ones it judges unsafe instead of prompting the developer each time. Organizations can turn it off with disableAutoMode in managed settings; deny rules still apply inside it.

Do organization skills load in Claude Code?

Yes: skills provisioned in the organization's library load in Claude Code for users signed in with their Claude account, and IT can stop the sync with syncClaudeAiSkills set to false.

Do we need Claude Enterprise to manage Claude Code centrally?

No. Anthropic's identity documentation describes Team as a self-service plan with admin tools, SSO, billing management and server-managed settings; Enterprise adds role-based permissions, the Compliance API and usage billed at API rates with admin spend limits.