Ask whether Claude Code is safe and you’ll get one answer stitched from two different questions. The first is about the tool: does it read files it shouldn’t, run commands you never approved, keep a copy of your source somewhere you can’t see. The second is about what it produces: is the code it writes safe to put in front of real users. Yes on the first, governed by a permission system stricter than most people assume, with the real limits laid out below instead of left to guesswork. Often no on the second, and that has nothing to do with the permission model at all.
This post answers both. The permissions and data-handling half comes from Anthropic’s current data usage documentation, fetched and checked line by line rather than repeated from memory. The shipped-code half comes from the record I keep as someone who audits apps built with these tools for a living: 26 real apps, the AxonBuild audit corpus, every finding verified against the code. Neither half is the scary version. Both are more specific than “be careful.”
Claude Code’s permission tiers, from read-only to org lockdown
Claude Code defaults to read-only. Inside the project folder where you started it, it can read files and run a fixed set of read-only commands, ls, cat, git status among them, without stopping to ask. The moment an action would change something, a file edit, a command like rm or mv, a git push, it stops and asks first, unless you’ve explicitly allowlisted that exact action or switched on Accept Edits mode for the session.
Reaching outside the folder it started in works the same way. Reading a path above the working directory, or fetching a URL with a network tool, triggers an approval prompt by default, and Accept Edits mode doesn’t waive it; the only ways past the prompt are ones you configure deliberately, an extra directory added via additionalDirectories or an allow rule for a named domain. curl and wget aren’t auto-approved either, since a tool that can read the internet on your behalf is also one a malicious webpage could try to instruct. Anthropic’s own security documentation calls this out specifically as a prompt-injection defense: content fetched from the web runs through a separate context window, so instructions buried in a page can’t quietly become instructions Claude follows.
The tier that surprises people is the organizational one. A company can ship a managed-settings.json policy file that overrides every project and user setting on a machine, and no local override can undo it. That’s the layer built for a security team that doesn’t trust individual configuration, and it answers “can an org lock this down” with a flat yes.
Four tiers, each with a different amount of rope:
- 01 Reads files in the project you started it in and runs a fixed set of read-only commands (ls, cat, git status) with no prompt at all
- 02 Edits a file, or runs a command that changes your system, and it stops to ask, unless you’ve allowlisted that exact action or turned on Accept Edits mode
- 03 Reaches outside the working directory, whether that’s a parent folder or a curl to a URL, and it asks by default, even inside Accept Edits mode, unless you’ve deliberately added that directory or allowlisted that domain
- 04 Runs inside an org with a managed-settings.json policy, and none of the above is yours to change: the managed layer overrides every project and user setting
None of this makes Claude Code incapable of doing something you’ll regret. It means the tool asks before doing it, which only helps if you actually read the prompt. That habit, not the permission system, is where “safe to use” usually breaks down in practice.
Is Claude safe to use with your code? Retention and training, by tier
This is the question nobody ranking for “is Claude safe” actually answers with numbers, and the numbers depend entirely on which account is running the session.
On a Free, Pro, or Max account, including when Claude Code runs from one of those accounts, your data is used for training only when the model-improvement setting is on. Anthropic asks you to make that choice rather than fixing it for you, and the setting can be changed any time in your data-privacy controls. With it on, retention runs up to 5 years; with it off, 30 days.
On a Team, Enterprise, or API account, the policy inverts. Anthropic does not train generative models on code or prompts sent under commercial terms, unless your organization has explicitly opted into a program built for that purpose (the Development Partner Program, API-only, opt-in at the org level). Standard retention on commercial accounts is 30 days. Qualified Enterprise accounts can request Zero Data Retention for Claude Code, though your account team has to enable it per organization; it isn’t a toggle in your own settings page.
Three retention windows sit outside both tiers. Anything you send through the /feedback command is retained for 5 years, because sending feedback is an explicit action that ships a copy of your session to Anthropic on purpose. The in-product session-quality survey has a quieter cousin of the same thing: a follow-up asking whether Anthropic can look at your session transcript, and saying yes uploads it (known API-key patterns redacted, source code as-is) for up to 6 months of retention. And Claude Code caches your own session transcripts locally, in plaintext, under ~/.claude/projects/ on your own machine, for 30 days by default, purely so you can resume a session, adjustable via the cleanupPeriodDays setting. It’s also where a stray API key from an old debugging session is probably still sitting, long after you forgot the session happened.
Claude Code security concerns: what the code it writes ships
The concern nobody measures has nothing to do with the permission model above. Line up the two halves of this post and the asymmetry is obvious:
The 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 AxonBuild audit 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.
Two findings from one app in that corpus have stayed with me because both are permissions stories dressed as database stories. 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, and a cascade executes as the table owner, ignoring the row-level security policies that blocked even the service role from deleting a ledger row. 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 wasn’t 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.
Using Claude Code safely
The permission architecture above is not a substitute for reading what Claude Code is about to do. Accept Edits mode is fine for a formatting pass and a bad idea on a branch that touches auth, payments, or anything that grants access: auto-approving every edit and reviewing every line that decides who gets in are opposite postures, and it’s easy to leave the convenient one on too long. Safety and cost are separate questions about the same tool, and what Claude Code costs on Pro versus Max answers the other one.
Three habits cover most of the gap between the tool being safe and the code being safe:
Review the diff on anything that grants, checks, or revokes access, every time, even when the change looks small. The run-any-SQL function above was dead code by the time I found it: the app had stopped calling it, the grant to anon and authenticated never went away, and a grant nobody remembers is exactly the kind of line a diff review exists to catch.
Keep secrets out of what Claude Code can read by default rather than trusting it to recognize one. A deny rule handles the reading; a matching line naming what never gets echoed into a chat response or a commit is what belongs in a CLAUDE.md alongside the fragile paths. A short deny rule in your settings file does the tool-level half, straight from Anthropic’s own settings documentation:
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
]
}
}Treat every MCP server you connect as its own permission grant, not a feature you turned on once: what an MCP server in Claude Code can actually reach is rarely obvious from the install step.
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, and so does the reason AI coding tools ship security holes by default: the holes never fail a demo, so nothing forces the review without the habit. If you want a read on where your own app stands against the same areas the corpus is scored on, the scorecard takes about two minutes and names the weakest one.
Common questions about Claude Code and safety
Does Claude Code train on my code?
Whether Claude Code trains on your code depends on the account. On Free, Pro, or Max, only when the model-improvement setting is on, a choice Anthropic asks you to make and one you can change any time. On Team, Enterprise, or API, no, unless your organization has explicitly opted into the Development Partner Program. The setting lives with the account, not with the tool.
What can Claude Code do without my permission?
On its own, Claude Code reads files in the project you started it in and runs a fixed set of read-only commands like ls and git status. Anything that edits a file, changes your system, or reaches outside that folder (including a network request) stops and asks first. Accept Edits mode pre-approves file edits only; commands and outside-folder reach still prompt unless you’ve explicitly allowlisted that action or path yourself.
Is Claude safe for sensitive data?
For data you can’t take back if it leaks: safe enough on a commercial account, with the default no-training policy and standard 30-day retention, safer still if your organization qualifies for Zero Data Retention. On a personal Free or Pro account, check your privacy settings before assuming.
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.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
