Claude Code security rests on a permission system that decides which actions need your approval, an optional OS-level sandbox for shell commands, and safeguards against prompt injection such as trust checks and network command approval. On top of that, /security-review and two security plugins look for vulnerabilities in the code itself.
None of this replaces your judgment. The official security page is direct about it: "You're responsible for reviewing proposed code and commands for safety before approval." This guide explains each layer and what you still need to do, based on that page and the related docs, read on 24 October 2026.
How does Claude Code keep you in control?
Every session runs in a permission mode that sets which actions Claude can take without asking. The two you meet most:
- Auto mode: the built-in starting mode for interactive terminal and VS Code sessions on Claude Code v2.1.283 or later, when auto mode is available to the session. A separate classifier model reviews actions in place of you and blocks the ones it judges unsafe. Your ask and deny rules still apply, and an organization can turn auto mode off.
- Manual mode: Claude starts read-only and asks before it edits files, runs tests or runs commands. You approve once or allow from then on. A built-in set of read-only commands such as
ls,catandgit statusruns without asking.
Accept Edits mode auto-approves file edits plus a fixed set of filesystem commands like mkdir, mv and sed inside the working directory, and still prompts for anything else.
In Manual mode there is also a working directory boundary: Claude's file tools ask before reading or writing outside the folder you started in. That boundary is a prompt, not an OS restriction, so an approved Bash command can still write anywhere your user account can. The Claude Code permissions guide covers rule syntax and modes in detail.
What does the Claude Code sandbox add?
The sandbox wraps shell commands in OS-level filesystem and network isolation. You turn it on with /sandbox, and sandboxed commands can only write inside your project and a temp folder and only reach network hosts you allow. Because the OS enforces those limits, Claude can run commands inside the boundary without asking each time.
Permission rules and the sandbox cover different gaps. A deny rule like Bash(curl *) matches the command as Claude writes it, so a differently written command can get around it. The sandbox's network allowlist does not depend on command text. The Claude Code sandbox guide covers setup, platforms and limits.
For more isolation still, the docs suggest running the whole Claude Code process inside the sandbox runtime or a dev container.
How does Claude Code defend against prompt injection?
Prompt injection is when an attacker hides instructions in content Claude reads, such as a web page, an issue or a file, to make it do something you didn't ask for. Claude Code's safeguards:
- Permission system: in Manual mode, sensitive operations need explicit approval.
- Network command approval: commands that fetch from the web, such as
curlandwget, are not auto-approved by default. - Web page summaries: for most fetches, WebFetch runs a separate model call over the page, and Claude receives that answer instead of the raw page.
- Trust verification: an interactive session shows a workspace trust dialog in a folder you haven't trusted, and servers in a project's
.mcp.jsonget their own approval prompt. A-psession shows neither. - Command injection detection: in Manual mode, Claude Code asks before running a Bash command it can't fully analyze, even if part of it matches an allow rule like
Bash(git *). - Fail-closed matching: in Manual mode, unmatched commands need approval by default.
- Secure credential storage: API keys and tokens go in the macOS Keychain when available, and in a file with mode
0600on Linux.
Anthropic's best practices for untrusted content:
- Review suggested commands before approval.
- Avoid piping untrusted content directly to Claude.
- Verify proposed changes to critical files.
- Use virtual machines to run scripts and make tool calls, especially with external web services.
- Report suspicious behavior with
/feedback.
The docs add a warning worth taking literally: "While these protections significantly reduce risk, no system is completely immune to all attacks."
On Windows, Anthropic recommends against enabling WebDAV or letting Claude Code access paths such as \\*, because WebDAV may let it trigger network requests that bypass the permission system.
How should you treat MCP servers, plugins and hooks?
Extensions run code with your access, so treat them like any dependency.
- MCP servers: project servers live in
.mcp.json, but servers at other scopes, claude.ai connectors and plugins can add more, so reading.mcp.jsondoesn't show everything a session can load. Anthropic encourages writing your own servers or using ones from providers you trust, and says it reviews connectors against listing criteria but "does not security-audit or manage any MCP server." - Plugins: read the official plugin security and trust page before installing, since a plugin can add skills, hooks and MCP servers at once.
- Hooks: hooks run shell commands outside the sandbox. A
ConfigChangehook can audit or block settings changes during a session. See the Claude Code hooks guide.
Organizations can lock this down with managed settings, for example allowing only approved MCP servers or marketplaces. The Claude Code enterprise guide lists the keys.
How do you scan code for vulnerabilities with Claude Code?
Claude Code offers four security review tools, which the security guidance page places in a typical stack alongside your CI scanners:
| Stage | Tool | What it covers |
|---|---|---|
| In session | Security guidance plugin | Common vulnerabilities in code Claude writes, fixed in the same session |
| On demand, single pass | /security-review |
One security pass over the changes on your current branch |
| On demand, deep scan | Claude Security plugin | Multi-agent scan of a repository or diff, with reviewed findings and patches |
| On pull request | Code Review (Team and Enterprise) | Multi-agent correctness and security review with full codebase context |
| In CI | Your existing static analysis and dependency scanners | Language-specific rules, supply-chain checks and policy enforcement |
/security-review reviews the diff between your branch and origin's default branch for risks like injection, auth issues and data exposure. It needs an origin remote.
The security guidance plugin runs automatically once installed, with nothing to invoke. It checks each edit with a fast pattern match, reviews each turn's changes in the background, and needs Python 3.7 or later. The deeper commit review needs Python 3.10 or later, as do all its model-backed reviews when Claude Code runs on a third-party provider such as Amazon Bedrock. Install it with:
/plugin install security-guidance@claude-plugins-official
The Claude Security plugin runs a team of agents that maps your architecture, builds a threat model, hunts for vulnerabilities and independently reviews each finding. It needs Python 3.9 or later, counts toward your usage, and installs with /plugin install claude-security@claude-plugins-official.
None of these replace your CI scanners and dependency checks, and the security guidance plugin never blocks writes or commits. For more on /code-review and pull request reviews, see the Claude Code review guide.
How secure are Claude Code cloud sessions?
Cloud sessions in Anthropic-hosted environments add their own controls:
- Each session runs in an isolated, Anthropic-managed VM.
- Network access is limited by default and can be disabled or limited to specific domains.
- GitHub credentials stay encrypted on Anthropic's servers and never enter the VM; a proxy attaches them server-side.
- The GitHub proxy rejects branch deletions and pushes of anything other than a branch, and your branch protection rules still apply.
- All operations are logged, and idle VMs are reclaimed.
Sessions routed to a self-hosted environment run on your infrastructure, so isolation, egress and credentials become your responsibility.
What security practices should teams follow?
For sensitive code, the docs recommend reviewing every change before approval, using project-specific permission settings for sensitive repositories, and auditing your permissions regularly with /permissions.
For teams:
- Enforce standards with managed settings.
- Share approved permission configurations through version control.
- Train team members on security practices.
- Monitor usage with OpenTelemetry metrics.
- Audit or block mid-session settings changes with
ConfigChangehooks.
Skills deserve the same review. A skill can include scripts that Claude runs, so read the SKILL.md and its files before you install one. Keeping your team's skills in Kipt, where they sit as Markdown in a private GitHub repo you own, means every change to a skill is a commit you can review. For hardening help, the security hardening skill and Semgrep skill are worth a look.
How do you report a Claude Code security issue?
If you find a vulnerability, don't disclose it publicly. Report it through Anthropic's HackerOne program, linked from the security page, with detailed reproduction steps, and allow time for a fix before going public. Anthropic's SOC 2 Type 2 report and ISO 27001 certificate are available from the Anthropic Trust Center.