​
Authentication methods

Setting up Claude Code requires access to Anthropic models. For teams, you can set up Claude Code access in one of three ways:
  • Anthropic API via the Anthropic Console
  • Amazon Bedrock
  • Google Vertex AI

​
Anthropic API authentication

To set up Claude Code access for your team via Anthropic API:
  1. Use your existing Anthropic Console account or create a new Anthropic Console account
  2. You can add users through either method below:
    • Bulk invite users from within the Console (Console -> Settings -> Members -> Invite)
    • Set up SSO
  3. When inviting users, they need one of the following roles:
    • “Claude Code” role means users can only create Claude Code API keys
    • “Developer” role means users can create any kind of API key
  4. Each invited user needs to complete these steps:

​
Cloud provider authentication

To set up Claude Code access for your team via Bedrock or Vertex:
  1. Follow the Bedrock docs or Vertex docs
  2. Distribute the environment variables and instructions for generating cloud credentials to your users. Read more about how to manage configuration here.
  3. Users can install Claude Code

​
Access control and permissions

We support fine-grained permissions so that you’re able to specify exactly what the agent is allowed to do (e.g. run tests, run linter) and what it is not allowed to do (e.g. update cloud infrastructure). These permission settings can be checked into version control and distributed to all developers in your organization, as well as customized by individual developers.

​
Permission system

Claude Code uses a tiered permission system to balance power and safety:
Tool TypeExampleApproval Required”Yes, don’t ask again” Behavior
Read-onlyFile reads, LS, GrepNoN/A
Bash CommandsShell executionYesPermanently per project directory and command
File ModificationEdit/write filesYesUntil session end

​
Configuring permissions

You can view & manage Claude Code’s tool permissions with /permissions. This UI lists all permission rules and the settings.json file they are sourced from.
  • Allow rules will allow Claude Code to use the specified tool without further manual approval.
  • Ask rules will ask the user for confirmation whenever Claude Code tries to use the specified tool. Ask rules take precedence over allow rules.
  • Deny rules will prevent Claude Code from using the specified tool. Deny rules take precedence over allow and ask rules.
  • Additional directories extend Claude’s file access to directories beyond the initial working directory.
  • Default mode controls Claude’s permission behavior when encountering new requests.
Permission rules use the format: Tool or Tool(optional-specifier) A rule that is just the tool name matches any use of that tool. For example, adding Bash to the list of allow rules would allow Claude Code to use the Bash tool without requiring user approval.

​
Permission modes

Claude Code supports several permission modes that can be set as the defaultMode in settings files:
ModeDescription
defaultStandard behavior - prompts for permission on first use of each tool
acceptEditsAutomatically accepts file edit permissions for the session
planPlan Mode - Claude can analyze but not modify files or execute commands
bypassPermissionsSkips all permission prompts (requires safe environment - see warning below)

​
Working directories

By default, Claude has access to files in the directory where it was launched. You can extend this access:
  • During startup: Use --add-dir <path> CLI argument
  • During session: Use /add-dir slash command
  • Persistent configuration: Add to additionalDirectories in settings files
Files in additional directories follow the same permission rules as the original working directory - they become readable without prompts, and file editing permissions follow the current permission mode.

​
Tool-specific permission rules

Some tools support more fine-grained permission controls: Bash
  • Bash(npm run build) Matches the exact Bash command npm run build
  • Bash(npm run test:*) Matches Bash commands starting with npm run test
  • Bash(curl http://site.com/:*) Matches curl commands that start with exactly curl http://site.com/
Claude Code is aware of shell operators (like &&) so a prefix match rule like Bash(safe-cmd:*) won’t give it permission to run the command safe-cmd && other-cmd
Important limitations of Bash permission patterns:
  1. This tool uses prefix matches, not regex or glob patterns
  2. The wildcard :* only works at the end of a pattern to match any continuation
  3. Patterns like Bash(curl http://github.com/:*) can be bypassed in many ways:
    • Options before URL: curl -X GET http://github.com/... won’t match
    • Different protocol: curl https://github.com/... won’t match
    • Redirects: curl -L http://bit.ly/xyz (redirects to github)
    • Variables: URL=http://github.com && curl $URL won’t match
    • Extra spaces: curl http://github.com won’t match
For more reliable URL filtering, consider:
  • Using the WebFetch tool with WebFetch(domain:github.com) permission
  • Instructing Claude Code about your allowed curl patterns via CLAUDE.md
  • Using hooks for custom permission validation
Read & Edit Edit rules apply to all built-in tools that edit files. Claude will make a best-effort attempt to apply Read rules to all built-in tools that read files like Grep, Glob, and LS. Read & Edit rules both follow the gitignore specification with four distinct pattern types:
PatternMeaningExampleMatches
//pathAbsolute path from filesystem rootRead(//Users/alice/secrets/**)/Users/alice/secrets/**
~/pathPath from home directoryRead(~/Documents/*.pdf)/Users/alice/Documents/*.pdf
/pathPath relative to settings fileEdit(/src/**/*.ts)<settings file path>/src/**/*.ts
path or ./pathPath relative to current directoryRead(*.env)<cwd>/*.env
A pattern like /Users/alice/file is NOT an absolute path - it’s relative to your settings file! Use //Users/alice/file for absolute paths.
  • Edit(/docs/**) - Edits in <project>/docs/ (NOT /docs/!)
  • Read(~/.zshrc) - Reads your home directory’s .zshrc
  • Edit(//tmp/scratch.txt) - Edits the absolute path /tmp/scratch.txt
  • Read(src/**) - Reads from <current-directory>/src/
WebFetch
  • WebFetch(domain:example.com) Matches fetch requests to example.com
MCP
  • mcp__puppeteer Matches any tool provided by the puppeteer server (name configured in Claude Code)
  • mcp__puppeteer__puppeteer_navigate Matches the puppeteer_navigate tool provided by the puppeteer server
Unlike other permission types, MCP permissions do NOT support wildcards (*).To approve all tools from an MCP server:
  • ✅ Use: mcp__github (approves ALL GitHub tools)
  • ❌ Don’t use: mcp__github__* (wildcards are not supported)
To approve specific tools only, list each one:
  • ✅ Use: mcp__github__get_issue
  • ✅ Use: mcp__github__list_issues

​
Additional permission control with hooks

Claude Code hooks provide a way to register custom shell commands to perform permission evaluation at runtime. When Claude Code makes a tool call, PreToolUse hooks run before the permission system runs, and the hook output can determine whether to approve or deny the tool call in place of the permission system.

​
Enterprise managed policy settings

For enterprise deployments of Claude Code, we support enterprise managed policy settings that take precedence over user and project settings. This allows system administrators to enforce security policies that users cannot override. System administrators can deploy policies to:
  • macOS: /Library/Application Support/ClaudeCode/managed-settings.json
  • Linux and WSL: /etc/claude-code/managed-settings.json
  • Windows: C:\ProgramData\ClaudeCode\managed-settings.json
These policy files follow the same format as regular settings files but cannot be overridden by user or project settings. This ensures consistent security policies across your organization.

​
Settings precedence

When multiple settings sources exist, they are applied in the following order (highest to lowest precedence):
  1. Enterprise policies
  2. Command line arguments
  3. Local project settings (.claude/settings.local.json)
  4. Shared project settings (.claude/settings.json)
  5. User settings (~/.claude/settings.json)
This hierarchy ensures that organizational policies are always enforced while still allowing flexibility at the project and user levels where appropriate.

​
Credential management

Claude Code securely manages your authentication credentials:
  • Storage location: On macOS, API keys, OAuth tokens, and other credentials are stored in the encrypted macOS Keychain.
  • Supported authentication types: Claude.ai credentials, Anthropic API credentials, Bedrock Auth, and Vertex Auth.
  • Custom credential scripts: The apiKeyHelper setting can be configured to run a shell script that returns an API key.
  • Refresh intervals: By default, apiKeyHelper is called after 5 minutes or on HTTP 401 response. Set CLAUDE_CODE_API_KEY_HELPER_TTL_MS environment variable for custom refresh intervals.