Is Claude Code Safe to Use?

Last updated: September 2026

Is Claude Code safe to use? Yes, and it is safer than most tools in its category, because it asks before it edits a file or runs a shell command, and its mistakes are visible and reversible. The real risk is not the tool going rogue. It is that people do not know where the boundary of the system they are building sits.

The short version

• The tool has real gates. File edits and shell commands require your approval by default. Reading files does not. That split is documented and worth knowing exactly.
• The gates protect your machine, not your project. Every incident I saw across a month of sessions came from outside the tool: a key on a screen, an endpoint with no auth, a database table with no policy on it.
• The failure mode is not knowing where the system ends. People imagine one boundary and the real one sits somewhere else. That is the whole problem, and it is fixable in about an hour.

What does Claude Code actually ask permission for?

This is the part most people never look up, and it takes two minutes. Claude Code runs a tiered permission system where the answer depends on the kind of action, not on how risky it feels.

Action	Does it ask first?	If you say yes to all
Reading files, searching code	No, inside your working directory	Not applicable
Shell commands	Yes, except a built-in set of read-only ones	Remembered per repository and command
Editing or writing files	Yes	Remembered until the session ends
Fetching a web page	Yes, except preapproved documentation domains	Remembered per repository and domain

Two things follow from that table. Claude Code can read your entire working directory without asking once, which is the point of it and also worth sitting with. And it cannot write to a file or run an arbitrary command without you agreeing first, which is the guardrail that matters.

There is also a read-only mode people underuse. In plan mode, per Anthropic's permissions documentation, "Claude reads files and runs read-only shell commands to explore but doesn't edit your source files". If you are nervous, or you are pointing it at something you care about for the first time, that is the setting to start in.

The mode to avoid is the one that skips prompts entirely. The docs are unusually blunt about it, warning that it also skips protection on paths like .git and .claude, and that you should "only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage". People turn it on to stop the interruptions and then forget it is on. That is the single most common way a safe tool becomes an unsafe one.

What does Claude Code not protect you from?

Here is where I have to be straight with you, because this is the part the security write-ups tend to skip.

Across a month of client sessions I logged four separate exposure incidents. Not one of them was Claude Code doing something it was not supposed to do. Every one was a boundary the person had not thought about.

An API key sat visible in a terminal during a working session and then went into a hosting dashboard. The fix there is rotation, not covering it up, and that distinction catches people out constantly.

A public endpoint went live carrying a server-side key, with no authentication and no spending cap on it. Anyone who had the URL could spend that account's credits. The obscurity of the link was doing all of the security work, which is another way of saying there was none.

Generated code turned out not to be secure by default. Database tables were readable until row-level policies were added, which would have let any signed-in user read every other user's records. The code worked. Working and safe are different tests, and only one of them is obvious from the screen.

The fourth was a near miss, and it is the one that cuts against the scary framing. An exported conversation transcript containing customer prompts was sitting inside a git repository folder, ready to be committed. Claude flagged it before it went in. The tool caught that one.

That is the honest picture. The pattern across two months of these is not that beginners paste keys into chat windows. It is that beginners do not know where the boundary of a system is. I wrote up the specific mechanics separately in the ways beginners leak credentials with AI tools, and that post is the checklist. This one is the reason the checklist keeps being necessary.

Two documented gaps are worth adding, because they surprise people who assume the sandbox covers more than it does.

The first is what a sandboxed command can still read. Anthropic's sandboxing documentation states that the default read policy gives "read access to the entire computer, except certain denied directories" and notes that this "still allows reading credential files such as ~/.aws/credentials and ~/.ssh/". You can lock those down, and if you keep cloud credentials on the machine you should. But the default is not what most people picture.

The second is platform coverage. The same page says the sandbox "is built into Claude Code and runs on macOS, Linux, and WSL2. Native Windows is not supported. On Windows, run Claude Code inside a WSL2 distribution." Claude Code itself installs and runs on Windows natively. It is the sandbox specifically that wants WSL2, which is one more reason I walk students through setting it up on Windows and WSL rather than letting them skip it.

There is one more that almost nobody publishes, and it matters if you clone repositories. A skill checked into a project can declare allowed-tools, which pre-approves tools for the turn that invokes it. The permissions documentation is explicit that "workspace trust never gates a skill's allowed-tools in any session". So a repository you have not trusted can still supply a skill that grants itself tool access. You would read a Makefile before running make on a stranger's project. A .claude/skills/ directory is the same category of thing, and hardly anyone treats it that way yet.

The trust dialog itself has an edge worth knowing, because it is the thing standing between you and an unfamiliar repository. It only appears in interactive sessions. A scripted run started with claude -p, or a session driven through the SDK, never shows it. In that situation the same documentation says MCP servers declared in a project's .mcp.json are "connected without asking, approved or not". If you are wiring Claude Code into a script, a scheduled job, or CI, you have quietly stepped outside the gate that protects you when you use it by hand. That is not a bug, and it is documented plainly. It is just not what anyone assumes.

None of this is an argument against the tool. I use it every working day and I teach it. It is an argument for spending twenty minutes learning what it gates and what it does not, once, before you point it at anything that matters. Most people spend that twenty minutes after the incident instead.

Is it safe to use Claude Code at work?

Usually yes, with one caveat that has nothing to do with security and catches people anyway.

On a work account, your conversations and uploaded files are not private from the organisation. Administrators see metadata as a matter of routine, and the account owner can export conversation content. That is normal and it is how corporate accounts are supposed to work. The mistake is assuming otherwise.

I had a student building a personal project on an employer's account. The concern that surfaced first was billing, and the proposed fix was to use a cheaper model so the spend would not stand out. That solves the wrong problem entirely. The risk was never the cost. It was that a personal portfolio and a CV sitting in a work account reads as job hunting to anyone who looks.

Use a personal account for personal work. Not because anything is being hidden, but because mixing the two creates a conversation you did not intend to have. If your employer has locked things down and you are trying to work out what you are actually allowed to use, I went through that whole decision in what to do when your company blocks Claude Cowork.

One last thing, and it is a judgment point rather than a setting. Language models do not tell you when they are unsure. Ask one to keep improving something and it will keep going indefinitely, sounding equally confident at every step. Nothing in the permission system protects you from that. That gap is where your own judgment does the work, and it is the reason I do not recommend anyone run this tool unattended on something that matters.

Frequently Asked Questions

Can Claude Code delete my files?

Only if you approve it. File modification requires your permission by default, and the sandbox additionally blocks writes to the files Claude Code loads its own configuration from. The exception is if you have turned permission prompts off, which removes that gate along with protection for paths like .git.

Can Claude Code leak my API keys?

Not by itself, but it can read them. Reading files inside your working directory does not prompt, and the sandbox's default read policy still allows access to credential files such as ~/.aws/credentials and ~/.ssh/. Keep secrets in environment files that are gitignored, restrict credential reads in your sandbox settings, and rotate anything that has been on screen.

Is it safe to use Claude Code on a work computer?

Technically yes, and most employers who allow it are fine with it. The real issue is that work accounts are not private: admins see metadata and owners can export conversations. Keep personal projects on a personal account.

Should I turn off the permission prompts to work faster?

No, not on a machine that holds anything you care about. Anthropic's own documentation restricts that mode to isolated environments like containers or VMs. If prompts are slowing you down, approve commands per repository or use plan mode for exploration instead.

Is Claude Code safe for someone who cannot read the code it writes?

Safe from damaging your machine, yes. Safe from shipping something insecure, no. Generated code is not secure by default, and the three exposure incidents I described all came from code that ran perfectly. If you cannot review it yourself, get it reviewed before anything goes public.

Not sure where your own boundary sits?

Most people find this out the expensive way, usually after something is already live. It takes about an hour to walk your setup and find the edge you had not thought about: what is in your repository, what your endpoints expose, what your account can see. Book a free Discovery Call and bring the project you are worried about.

Written by Michael Murr for AI Tutor Code: private 1-on-1 online tutoring for professionals learning Python, AI tools, Data Science, ML, and LLM engineering. 200+ students taught, 3,000+ hours delivered.