Your code’s security is paramount. Claude Code is built with security at its core, developed according to Anthropic’s comprehensive security program. Learn more and access resources (SOC 2 Type 2 report, ISO 27001 certificate, etc.) at Anthropic Trust Center.
A session’s permission mode sets which actions Claude can take without asking you first. Auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions. Which mode a session starts in covers earlier versions, other surfaces, and the settings that change the starting permission mode.
Auto mode: A separate classifier model reviews actions instead of you and blocks the ones it judges unsafe. How the classifier evaluates actions lists which actions Claude Code approves outright, which it sends to the classifier, and which Claude Code still asks you about. Your explicit ask and deny rules still apply, and your organization can turn auto mode off
Manual mode: Claude Code starts with read-only permissions. When it needs to edit files, run tests, or execute commands, it asks you first, and you choose whether to approve the action once or allow it from then on. It runs a built-in set of read-only commands such as ls, cat, and git status without asking
You and your organization configure these permissions directly. For detailed permission configuration, see Permissions.
Sandboxed bash tool: Sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security. Configure with /sandbox to define boundaries where Claude Code can work autonomously
Working directory boundary: In Manual mode, Claude Code asks you before its file tools read or write outside the folder where it was started and its subfolders. The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can
To restrict Bash commands at the operating system level, turn on sandboxing
Prompt fatigue mitigation: Support for allowlisting frequently used safe commands per-user, per-codebase, or per-organization
Accept Edits mode: Auto-approves file edits and a fixed set of filesystem Bash commands like mkdir, touch, rm, mv, cp, and sed for paths in the working directory. Other Bash commands and out-of-scope paths still prompt
Prompt injection is a technique where an attacker attempts to override or manipulate an AI assistant’s instructions by inserting malicious text. Claude Code includes several safeguards against these attacks:
Permission system: In Manual mode, sensitive operations require explicit approval
Network command approval: Commands that fetch content from the web such as curl and wget are not auto-approved by default. In Manual mode they prompt like any other non-read-only Bash command, so you can still approve once or add an explicit allow rule like Bash(curl *). To stop Claude from running them, add them to permissions.deny. A deny rule matches the command as written; for network enforcement that doesn’t depend on the command text, see sandbox network isolation
Network request approval: In Manual mode, most tools that make network requests require user approval by default
Web page summaries: For most fetches, WebFetch runs a separate model call over the page, and Claude receives that call’s answer instead of the raw page. See WebFetch tool behavior
Trust verification: In an interactive session, Claude Code shows the workspace trust dialog when you start it in a folder you haven’t trusted. Servers in a project’s .mcp.json have their own approval prompt, and Project scope lists the sessions that skip it
Note: When you start Claude Code directly in your home directory, trust acceptance is held for the current session only and is not written to disk, so the prompt reappears on each launch. There is no setting to persist it. Start Claude Code from a project subdirectory instead, where trust acceptance is saved per directory
Command injection detection: In Manual mode, Claude Code asks before running a Bash command it can’t fully analyze. An allow rule for part of a command, such as Bash(git *), doesn’t skip that prompt. Sandboxed commands can run without it
Fail-closed matching: In Manual mode, unmatched commands require approval by default
Secure credential storage: API keys and tokens are stored in the macOS Keychain when available. On Linux they’re stored in a file with mode 0600, and on Windows in a file that inherits the access controls of your user profile directory. See Credential Management
Windows WebDAV security risk: When running Claude Code on Windows, we recommend against enabling WebDAV or allowing Claude Code to access paths such as \\* that may contain WebDAV subdirectories. WebDAV has been deprecated by Microsoft due to security risks. Enabling WebDAV may allow Claude Code to trigger network requests to remote hosts, bypassing the permission system.
Best practices for working with untrusted content:
Review suggested commands before approval
Avoid piping untrusted content directly to Claude
Verify proposed changes to critical files
Use virtual machines (VMs) to run scripts and make tool calls, especially when interacting with external web services
Report suspicious behavior with /feedback
While these protections significantly reduce risk, no system is completely
immune to all attacks. Always maintain good security practices when working
with any AI tool.
You can connect Claude Code to Model Context Protocol (MCP) servers. Project-scoped servers are defined in .mcp.json, which you can check into source control. Servers at other scopes and claude.ai connectors are configured outside the repository, and plugins can add servers too, so reviewing .mcp.json doesn’t show every server a session can load. To restrict which servers run in your organization, see Managed MCP configuration.We encourage either writing your own MCP servers or using MCP servers from providers that you trust. You are able to configure Claude Code permissions for MCP servers. Anthropic reviews connectors against its listing criteria before adding them to the Anthropic Directory, but does not security-audit or manage any MCP server.
When you use cloud sessions, additional security controls are in place. Sessions your organization routes to a self-hosted environment run on your own infrastructure, where isolation, network egress, and git credentials are your deployment’s responsibility. In Anthropic-hosted environments:
Isolated virtual machines: Each cloud session runs in an isolated, Anthropic-managed VM
Network access controls: Network access is limited by default and can be configured to be disabled or allow only specific domains
Credential protection: GitHub credentials are stored encrypted on Anthropic’s servers and never enter the session VM. The VM holds a short-lived credential scoped to that session, and GitHub traffic goes through an Anthropic proxy that attaches the GitHub credential on the server side. See GitHub authentication options for how you grant access
Push restrictions: The GitHub proxy rejects branch deletions and pushes of anything other than a branch, such as a tag. GitHub decides which branches a session can update by applying your repository’s branch protection rules and rulesets to the GitHub access you connected. A rule that access can bypass doesn’t block a session’s push
Audit logging: All operations in cloud sessions are logged for compliance and audit purposes
Automatic cleanup: Session VMs are reclaimed after a period of inactivity
For more details on cloud execution, see Use Claude Code in the cloud; to configure network access for cloud sessions, see Configure cloud environments.Remote Control sessions work differently: the web interface connects to a Claude Code process running on your local machine. All code execution and file access stays local, and session traffic travels through the Anthropic API over TLS; while connected, the session transcript is stored on Anthropic servers to sync the conversation across devices, as described in Connection and security. No cloud VMs or sandboxing are involved. The connection uses multiple short-lived, narrowly scoped credentials, each limited to a specific purpose and expiring independently, to limit the blast radius of any single compromised credential.
