Is Claude Code Safe? Permissions, Data Use, and Practical Limits

Is Claude Code safe? The short answer

Yes for normal work, with conditions. Four lines:

• Safe for everyday repository work in default mode, on a clean branch, in a project directory that holds no secrets.
• Not safe when readable secrets sit inside that directory. Nothing has to edit them for them to reach the model.
• Not safe in bypassPermissions mode, or its CLI flag --dangerously-skip-permissions, outside a container or VM.
• Not a claim about your code. No permission mode says anything about whether the app it writes is secure. That is a separate review.

Checked against Anthropic’s current Claude Code documentation on 5 August 2026. Product behavior moves fast, so recheck the linked pages before you set a policy for a team.

Claude Code can be used safely on a real codebase when its permissions match the task and you review the changes it proposes. Its default mode asks before its first use of tools that edit files or run consequential commands. That gives you a useful control point. The protection gets weaker when approvals become routine, sensitive files remain readable, or a session receives credentials that reach production.

The product also sends prompts, selected file contents, and model output to the configured model provider. Anthropic’s retention and training rules depend on your account type and privacy choices. A safe setup therefore has three parts: tool permissions, data-handling settings, and review of the code that will eventually run for users.

What Claude Code can do by default

Anthropic describes Claude Code’s standard behavior as read-only by default. Built-in read-only commands such as ls, cat, and git status can run without a prompt. Editing files, running other shell commands, and accessing paths outside the working-directory boundary normally require approval.

That sentence needs two qualifications.

First, Claude Code can read files in the directory where you launched it. If .env, private keys, exported customer data, or production logs sit inside that boundary, the absence of an edit permission does not make them appropriate context. Second, permission prompts govern tool calls. They do not validate whether a generated authentication check, SQL policy, or payment handler is correct.

What the permission prompt is actually asking

Before the modes, the prompt itself. It offers three answers: allow this one call, allow it and stop asking, or decline. What “stop asking” means depends on the tool. A saved Bash approval is written to .claude/settings.local.json at the repository root and applies to later sessions in that repository. A file-modification approval is not written to a file at all. It lasts until the session ends.

Read the path in the request before you answer, because the prefix tells you how far outside your project the call reaches.

On a Bash or PowerShell prompt, press Ctrl+E for a plain-language explanation of the command, labeled Low risk, Med risk, or High risk. It is generated only when you press it, and showing it does not run the command.

One trap applies when you write rules instead of answering prompts. In a permission rule, a single leading / anchors to the settings file that defined the rule rather than to the filesystem root, so Read(/secrets/**) in your user settings blocks ~/.claude/secrets/** and not your project. Use // for a real absolute path, as in Edit(//tmp/scratch.txt).

Anthropic currently documents six permission modes:

acceptEdits covers more than text edits. Anthropic’s permission-mode documentation says it also auto-approves a fixed set of filesystem commands, including mkdir, touch, rm, mv, cp, and sed, when they target allowed directories. Treat the mode as write access to the working tree, then rely on version control for recovery.

Is --dangerously-skip-permissions ever safe?

Only inside a container or VM you would be willing to throw away. The CLI flag --dangerously-skip-permissions and the bypassPermissions mode are the same setting: the documentation lists the flag as equivalent to --permission-mode bypassPermissions.

bypassPermissions deserves its blunt name. Anthropic recommends using it only in an isolated environment because it permits writes to configuration directories and skips the prompts that normally interrupt a harmful command. A small circuit breaker still covers removal of the filesystem root or home directory, but that narrow exception does not make the rest of the machine safe.

The configuration directories are named in the docs: .git, .config/git, .claude, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, and .mvn. That is the part people miss. A session in this mode can rewrite the settings that were supposed to constrain it, and can edit a repository’s git hooks.

What still prompts is a short list: explicit ask rules, connector tools your organization set to ask, MCP tools marked requiresUserInteraction, and removals aimed at the filesystem root or your home directory, such as rm -rf / and rm -rf ~. Everything else runs.

To take the mode off the table entirely, set permissions.disableBypassPermissionsMode to "disable" in a settings file. In managed settings, nobody can override it.

Are Claude Code permission rules real enforcement?

Yes. Allow, ask, and deny rules are enforced by the Claude Code client. A sentence in CLAUDE.md influences the model’s behavior; a permission rule controls whether the client lets a matching tool call proceed.

Rules use deny-first precedence. If one scope denies Bash(aws *), a more specific allow rule cannot reopen an AWS command. You can review the active rules with /permissions and inspect which settings file supplied them.

A conservative project setup might begin here:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

There is an important boundary in Anthropic’s documentation: Read and Edit rules cover built-in file tools and recognized shell utilities, but they cannot stop every arbitrary subprocess from opening a file. Claude Code’s sandbox adds operating-system-level filesystem and network restrictions for Bash commands and their children. For a repository containing genuinely sensitive material, use permission rules and sandboxing together.

The same distinction applies to CLAUDE.md guardrails. A rules file can require a test before changing an auth path. The build has to run that test, and the permission layer has to control what the agent can touch.

Three gotchas the docs bury

The -p flag turns off trust verification. A first run in a new codebase, and every new MCP server, normally requires a trust prompt. Anthropic’s security page says that check is disabled when Claude Code runs non-interactively with -p. Any script, cron job, or CI step that shells out to claude -p skips the one gate designed to stop a hostile repository from running on first contact.

Trust acceptance is not saved when you start in your home directory. Launch Claude Code directly in ~ and the trust decision holds for the current session only. It is not written to disk, there is no setting to persist it, and the prompt returns on every launch. Start from a project subdirectory instead, where acceptance is saved per directory. Launching from home is also the setup that puts every file you own inside the read boundary.

On Windows, WebDAV can route around the permission system. Anthropic recommends against enabling WebDAV, or letting Claude Code access paths such as \\* that may contain WebDAV subdirectories, because enabling it may allow Claude Code to trigger network requests to remote hosts that bypass the permission system. Microsoft has deprecated the WebClient service for its own security reasons.

What sandboxing actually blocks, and how to turn it on

Run /sandbox in a session. That opens the sandbox panel, where you pick the mode and see whether anything is missing. On macOS there is nothing to install, because the sandbox uses the built-in Seatbelt framework. On Linux and WSL2 it needs two packages, and the panel names them. Native Windows is not supported, so run Claude Code inside a WSL2 distribution there.

The sandbox covers Bash commands and every process they spawn, enforced by the operating system. That is the job permission rules cannot do. A rule governs Claude Code’s own file tools and recognized shell utilities; the sandbox governs npm, terraform, kubectl, and anything else a command starts.

It has two independent layers, and they default in opposite directions.

Read the filesystem default twice. Turning sandboxing on stops writes outside the project and leaves reads wide open until you say otherwise, so your credentials stay readable. This is the config that fixes it:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

Two catches. denyRead rules apply only while sandboxing is enabled, so the rule sitting in a settings file does nothing on its own. And that . resolves to the project root only when the file is the project’s .claude/settings.json. Put the same block in ~/.claude/settings.json and . resolves to ~/.claude, which leaves your project unreadable and teaches you nothing about why.

Sandboxing is the wrong tool for an untrusted repository or an install script you have not read. For those, use a dev container or a disposable VM. Anthropic’s own guidance says the same: use a VM to run scripts and make tool calls, especially when the work touches external web services.

Does Claude Code train on your code?

Account type and privacy settings decide the answer. Anthropic’s data-usage documentation currently states:

Claude Code also stores resumable session transcripts locally in plaintext under ~/.claude/projects/ for 30 days by default. cleanupPeriodDays changes that local period. A laptop backup, shared workstation account, or support bundle can therefore matter even when server-side retention is short.

Feedback follows separate rules. Transcripts submitted through /feedback, /bug, or /share are retained for five years. A session-quality rating alone does not upload the transcript, but a separate follow-up can ask for permission to send it. If accepted, that upload can include source code and file contents after known token patterns are redacted, and Anthropic says it may be retained for up to six months.

For sensitive code, check the privacy setting and provider before the first session. Claude Code can run against Anthropic, Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry, and storage controls differ by provider.

The six Claude Code security risks that survive the permission prompts

Permission prompts reduce accidental machine changes. Six material risks remain:

1. 01 Approval fatigue. A prompt protects you only when you read the command, path, and reason before accepting it. Anthropic treats prompt fatigue as a design problem and answers it with allowlists, which is a trade rather than a fix.
2. 02 Readable secrets. A file inside the allowed boundary can enter model context even when the agent never edits it, and the sandbox read default still permits reads of ~/.ssh/ and ~/.aws/credentials.
3. 03 Prompt injection. Web pages, issues, logs, dependency READMEs, and tool output can carry instructions written to steer the agent. Claude Code isolates the WebFetch context and detects command injection, and Anthropic still says no system is immune.
4. 04 Supply-chain exposure. Untrusted repositories, install scripts, package installs, and third-party MCP servers all run code or feed input on your machine. Anthropic reviews connectors against listing criteria before adding them to its directory, but does not security-audit or manage any MCP server.
5. 05 Data exfiltration. An agent that can read secrets and reach the network is one bad instruction away from sending them somewhere. Permission prompts are weakest here, because an outbound call can look exactly like a normal build step.
6. 06 Insecure generated code. A clean permission decision says nothing about tenant isolation, webhook verification, race conditions, or failure handling in the generated diff.

Anthropic mitigates prompt injection with approval prompts, isolated WebFetch context, command-injection detection, and workspace trust. Its own security guidance still recommends reviewing critical files and using a VM when tools interact with untrusted external services.

Connected services widen the boundary. An MCP server can expose a database, browser session, source-control account, or payment system to the agent. Claude Code permissions can restrict MCP tools, but the server’s credential determines what the remote system will accept. Review Claude Code MCP servers, their scopes and permissions as a separate permission grant.

Generated code needs its own review path. Check authentication, authorization, payment state changes, destructive database operations, and expensive endpoints in the diff. Run tests with two accounts when ownership matters. Keep deployment credentials out of the coding session where possible. These controls are useful with every coding agent because AI-generated security failures often pass a one-user demo.

Is the code Claude Code writes secure?

Line up the two halves of the question and the asymmetry is obvious:

The AxonBuild audit corpus doesn’t tag findings by which AI tool wrote which line, so I can’t hand you a Claude-Code-specific vulnerability rate, and anyone who claims to have one for a single coding agent is almost certainly extrapolating past their own data. What I can hand you is what shipped anyway, across real apps built with the AI coding tools founders actually reach for, Claude Code among them, run through the same audit regardless of what built them.

The number worth sitting with: 958 confirmed findings across the 21 third-party apps in the corpus, roughly 46 per app, and only 58 of those were critical. That ratio is the actual point. Most of what an audit turns up is cleanup, not danger, and what an AI app security audit actually checks is most of what makes an audit worth paying for over a raw scanner report.

Can Claude Code check its own work?

To a point. /security-review runs an on-demand security pass over the changes on your current branch. The security-guidance plugin goes further and runs while Claude works: a pattern match on each edit for risky calls like eval( and .innerHTML =, a background model review of everything a turn changed, and a deeper agentic review whenever Claude commits or pushes. Those reviews run as a separate Claude call with fresh context, so the instance that wrote the code is not the one grading it.

Now the limits, which Anthropic states plainly. None of the layers block a write or a commit. Findings arrive as instructions for Claude to act on, and the reviewing model can miss things. The end-of-turn review covers up to 30 changed files per turn, and commit reviews are capped at 20 per rolling hour. Above all, no diff-level reviewer knows your tenancy model, your row-level security policies, or which database grant stopped being needed two releases ago. That last category is where the expensive findings live.

Two real findings from apps that passed every permission prompt

Two findings from one app in that corpus have stayed with me because both are permissions stories dressed as database stories. The corpus records the code that shipped, not the prompts or the approvals that produced it, so what follows is what the app contained. The first was a Postgres function wired to run arbitrary SQL text, dead code the app no longer called, still granted to the anon and authenticated roles: anyone holding nothing more than the public key had a read-anything backdoor into the schema.

The second lived in the same database’s foreign keys. The financial ledger tables were chained ON DELETE CASCADE all the way up to the organizations table, which automatically deletes referencing rows when the parent is deleted. PostgreSQL separately says that referential-integrity checks bypass row security. That is narrower than saying every cascade action bypasses RLS. In this app’s schema, one hard delete of an org, from the dashboard, a cleanup script, or a GDPR erase, would wipe every wallet and billing record with no undo. The tool that built all of it did nothing reckless. It made each piece work, which is what it was asked to do. Nobody asked it to revoke the grant on the function once the app stopped using it, and nothing in any prompt ever said the ledger had to survive its parent row.

Is Claude Code secure is the wrong question to stop at. The permission model governs what the tool does to your machine. It says nothing about what the code it writes does to your users.

None of this is specific to Claude Code, and how the other coding agents handle the same permission question is the shorter way to see that. The same review discipline that closes the launch-readiness gap between a demo and a real app applies here: the holes never fail a demo, so nothing forces the review without the habit.

Which Claude surface are you actually using?

Five products carry the Claude name and they do not share a risk shape. Two questions separate them: where the work runs, and where the transcript lives.

If a vendor questionnaire or a client contract is in play, name the surface in the answer. “We use Claude Code” and “we use Claude Code on the web” are different statements about where the customer’s code sits.

Is Claude Code safe for a company?

Start with the paperwork, because that is what the review actually asks for. Anthropic publishes the SOC 2 Type 2 report and the ISO 27001 certificate through the Anthropic Trust Center, which is where most security questionnaires end. Vulnerabilities go to Anthropic through a HackerOne program rather than a public issue tracker, so there is a named disclosure path to cite.

Then the controls an admin sets. Managed settings sit at the top of the precedence order and cannot be overridden by user or project settings.

Three entries in that file do most of the work: permissions.deny for paths nobody should read, permissions.disableBypassPermissionsMode set to "disable" so no one can run --dangerously-skip-permissions, and permissions.disableAutoMode if you want the classifier mode off too.

Two more org controls are worth knowing. Claude Code emits OpenTelemetry metrics, so usage is monitorable like any other tool in the stack. And ConfigChange hooks can audit or block settings changes during a session, which closes the gap where a running session edits the configuration meant to govern it.

How to use Claude Code safely: an 8-step setup

Use this sequence before giving Claude Code a repository with live-business consequences:

1. 01 Launch it from the narrowest useful project directory, then inspect any additional directory before granting access.
2. 02 Assume there is no undo for shell commands. /rewind restores files Claude edited with its file tools, but checkpointing does not track files changed by a bash command, so an rm, mv, or cp cannot be rewound, and acceptEdits auto-approves all three. Work on a clean branch or copy the folder first.
3. 03 Run /permissions and keep default or plan mode until you understand the commands and files the task needs.
4. 04 Deny reads of secrets, exports, private keys, and production data. Move them outside the project when practical.
5. 05 Enable sandboxing for broad shell work in code you trust; for an untrusted repository or an install script you have not read, use a dev container or a disposable VM instead.
6. 06 Use narrow, revocable credentials for MCP servers and production services. Avoid giving a coding session an admin token.
7. 07 Work on a clean branch, inspect the final diff, run the relevant tests, and review every change to auth, payments, and data ownership.
8. 08 Check the account privacy setting, local transcript retention, and feedback behavior against the sensitivity of the repository.

This does not require distrusting the tool. It gives each layer one job: permissions constrain actions, the sandbox constrains processes, privacy settings govern retained data, and code review protects the people who will use what you ship. Safety and cost are separate questions about the same tool, and Claude Code pricing on Pro versus Max answers the other one.

Common questions about Claude Code safety

Can Claude Code read my .env file?

It can read files inside its working-directory boundary unless a permission rule or sandbox restriction blocks access. Add an explicit Read(./.env) and Read(./.env.*) deny rule, and keep highly sensitive credentials outside the project directory.

Can Claude Code run commands without asking?

Built-in read-only commands can run without a prompt. Other commands depend on the active permission mode, allow rules, and sandbox configuration. acceptEdits, auto, and bypassPermissions each reduce prompting in different ways, so check /permissions rather than inferring the boundary from the interface label.

Does Claude Code train on my code?

It depends on the plan and on a setting. On Free, Pro, and Max accounts, data may train future models when that setting is enabled, with 5-year retention on and 30-day retention off. Team, Enterprise, and API use falls under commercial terms, where Anthropic does not train generative models on your code or prompts unless you opt into a model-improvement program, and standard server retention is 30 days.

Check the setting before the first session on a repository you care about, not after.

Is it safe to run Claude Code with --dangerously-skip-permissions?

Only inside a container or VM you would be willing to throw away. The flag is the same setting as bypassPermissions mode, and it skips prompts for writes to configuration directories including .git, .claude, and .devcontainer, so a session can rewrite the rules meant to constrain it. A few prompts survive, mainly explicit ask rules and removals aimed at the filesystem root or your home directory. On a machine holding real credentials, there is no safe version of this.

Can Claude Code find security bugs in its own code?

Partly. /security-review runs a one-time security pass over the changes on your current branch, and the security-guidance plugin reviews Claude’s own diffs as it works, using a separate model call with fresh context. Neither blocks a write or a commit, and neither knows your tenancy model, your row-level security policies, or which database grants are dead. Treat both as one layer of review, not the review.

Is Claude Cowork safe?

Cowork runs its work in an isolated, temporary environment on Anthropic servers, and reaches your computer only through the Claude Desktop app, for folders you connect. That makes the connected folders and connectors your real boundary rather than the machine itself. It offers three approval modes (manually approve, automatically approve, skip all approvals), and file deletion always asks. The risk Anthropic’s own guidance leads with is prompt injection from content Claude reads outside your trusted boundary.

Is Claude Code suitable for proprietary code?

It can be, provided the organization’s provider, contract, retention setting, device controls, and repository permissions meet its requirements. Commercial accounts have a no-training default under Anthropic’s current terms, while standard server retention remains 30 days unless qualified Zero Data Retention is enabled.

Does Claude Code make the code it writes secure?

No permission mode establishes that. Permissions govern agent actions on tools and files. Security in the resulting application still depends on tests, code review, deployment configuration, and runtime controls.

Is Claude Desktop safe?

The same account-tier retention and training policy applies, since it follows your account, not which surface you’re using. The added risk surface is specific to Desktop: whichever local MCP servers or extensions you’ve connected can reach whatever they’re built to reach. Review each one the way you’d review a permission grant, because that’s what it is.