Short answers to what readers ask most about this topic.
Read-only by default, an asymmetric directory boundary, and an accept-edits list that quietly includes rm. Here is what actually gates an agentic session.
Matthews Wong
Software Engineer
Key Takeaway
Claude Code in manual mode starts read-only and asks before editing files or running system-modifying commands. The working-directory boundary is asymmetric: writes are confined to the start folder and its subfolders, reads outside it prompt in manual mode but not in auto mode. Accept-edits auto-approves file edits plus a fixed set of filesystem commands.
I switched a session to accept-edits mode expecting it to auto-approve file writes, which is what the name says. It also auto-approved a remove command, on a path inside my working directory, without asking. Nothing went wrong and nothing was lost, but I had been running the mode for weeks with a mental model that was narrower than the actual behaviour.
The security model here is layered and mostly sensible, and the useful thing is knowing precisely where each layer stops. This post covers the permission architecture and what read-only actually means, the directory boundary and why it behaves differently per mode, the prompt-injection defences, the trust dialog and its home-directory quirk, and where cloud execution differs from a local session.
In manual mode Claude Code starts with read-only permissions and asks before editing files, running tests, or executing commands. There is a built-in set of read-only commands it runs without asking — directory listings, file reads, repository status — and everything else prompts, with the choice of approving once or allowing it from then on.
Auto mode replaces you rather than the gate: a separate classifier model reviews actions and blocks the ones it judges unsafe. Your explicit ask and deny rules still apply on top, and an organisation can turn auto mode off entirely. Which mode a session starts in depends on your plan, the surface you started it from, and both your settings and your organisation's — which is why two people on the same team can see different default behaviour and both be configured correctly.
Writes and reads are treated differently, and the difference between modes is on the read side only. This is worth internalising because a mental model of one boundary is wrong in both directions.
# The working-directory boundary is NOT symmetric, and it
# changes between permission modes.
# Manual mode
# WRITE -> only the folder Claude Code started in, and its
# subfolders. Parent directories need explicit
# permission.
# READ -> asks before Read, Grep and Glob touch a path
# outside that boundary.
# Auto mode
# READ -> reads outside the boundary WITHOUT asking.
# Widen it deliberately with additional directories, or narrow
# the broad read access that read-only Bash commands get with
# sandbox denyRead rules — which apply only when sandboxing
# is actually enabled.The name undersells it. Accept-edits auto-approves file edits and a fixed set of filesystem commands for paths in the working directory — and that set includes remove and move as well as the harmless ones. Other commands and out-of-scope paths still prompt, so the mode is genuinely bounded, but the bound is wider than the label suggests.
# What "accept edits" really auto-approves. It is not
# "everything" — it is file edits plus a FIXED set of
# filesystem Bash commands, for paths inside the working
# directory:
mkdir touch rm mv cp sed
# Anything else, and any out-of-scope path, still prompts.
#
# Worth knowing that rm and sed are on that list. "Accept
# edits" sounds narrower than it is.
# Commands that fetch from the web are NOT auto-approved by
# default at any level:
curl wget
# In manual mode they prompt like any other non-read-only
# command. To block them outright rather than prompt:
# permissions.deny: ["Bash(curl *)", "Bash(wget *)"]Commands that fetch content from the web are deliberately not auto-approved at any level. In manual mode they prompt like any other non-read-only command, so you can approve once or add an explicit allow rule. That default exists because a fetch is the step that turns a prompt-injection payload into an outbound request — if you are going to add a blanket allow rule for anything, this is the worst candidate.
No single mechanism here is a complete answer, and Anthropic says so plainly. What they add up to is several independent chances to catch the same attack:
First-time runs in a codebase and newly added MCP servers both require trust verification. Two caveats matter more than the feature. Trust verification is disabled entirely when running non-interactively with the prompt flag, which is correct — there is nobody to ask — but means an automated run does not get this layer. And starting Claude Code directly in your home directory holds trust for the current session only, never writing it to disk, so the prompt reappears on every launch.
There is no setting to persist home-directory trust, and that is deliberate rather than an oversight — your home directory contains everything, so accepting it once permanently would be a much larger grant than accepting a project. If the repeated prompt is annoying you, the fix is to start Claude Code from a project subdirectory, where trust is saved per directory. Treat the recurring prompt as the design telling you something.
These get conflated constantly, and they have genuinely different security properties. Getting them straight matters most when someone asks where the code runs, because the honest answer differs per surface.
Three surfaces, three answers:
| Surface | Where code executes | Notable controls |
|---|---|---|
| Local terminal or IDE | Your machine | Permissions, sandboxing, the directory boundary |
| Claude Code on the web | An isolated Anthropic-managed VM | Network limits, scoped git credentials, pushes restricted to the working branch, audit logging |
| Remote Control | Your machine, driven remotely | No cloud VM at all; short-lived scoped credentials, transcript stored to sync devices |
Stripping out the generic advice, four things change the risk profile measurably:
Credentials are stored in the operating system keychain where one is available, and protected by file permissions on Windows and Linux. That difference is worth knowing before you decide how much a compromised container matters: on macOS the keychain is a real boundary, and on a Linux CI host the protection is filesystem permissions, which is a much weaker claim in a container someone else can enter.
The model is layered rather than absolute, and every layer names its own limit if you read for it. Claude Code only has the permissions you grant it, and reviewing what you are approving is genuinely part of the design rather than a disclaimer. The two habits worth building are reading the command in the prompt rather than the shape of it, and knowing which mode you are in — because the same action gets a different amount of scrutiny depending on an answer most people stop checking after the first week.