What does acceptEdits allow?
claude --permission-mode acceptEditsOr press Shift+Tab once from Manual mode.
Answer
acceptEdits lets Claude create and edit files without asking, plus seven filesystem commands: mkdir, touch, rm, rmdir, mv, cp, and sed. Auto-approval covers only paths inside your working directory or additionalDirectories. Everything else, meaning other shell commands, paths outside that scope and writes to protected paths, still prompts.
What it does
acceptEdits removes the prompt from file edits. Claude creates and changes files in your working directory directly.
claude --permission-mode acceptEditsIt also auto-approves a fixed set of filesystem commands:
mkdir touch rm rmdir mv cp sedA prefix does not necessarily break the match. These stay approved when wrapped in an environment variable that only affects output formatting such as LANG=C or NO_COLOR=1, or in a process wrapper such as timeout, nice, or nohup.
The scope limit matters more than the list. Auto-approval applies only to paths inside your working directory, or to directories you added with --add-dir or the additionalDirectories setting. Four things still prompt:
- paths outside that scope
- writes to protected paths such as
.gitand.claude rmorrmdiraimed at a critical path, such as/, your home directory or the working directory itself, even thoughrmis on the list- every other Bash command
That last one has one exception, and it applies in every mode: a built-in set of read-only commands runs without asking: ls, cat, grep and about a dozen more, listed in full under why Claude Code keeps asking. The set is not configurable. To make one of them prompt, add an ask or deny rule for it.
With the PowerShell tool enabled, the mode also covers Set-Content, Add-Content, Clear-Content, and Remove-Item on in-scope paths, under the same rules. Remove-Item gets a check of its own, and a positional argument containing a quote character still prompts even on an in-scope path; pass the content through -Value instead.
When to use it
The mode fits work where you review the result rather than each step:
- a batch of mechanical edits you have already scoped
- refactors where you will read
git diffafterwards - any task where per-edit approval is noise, not oversight
The review still happens. It moves from inline prompts to your editor or your diff. That trade is good when the edits are numerous and individually boring.
When not to use it
Skip it when you want to see the plan before any file changes. That is plan mode, which blocks edits until you approve.
It is also the wrong tool if what you want is fewer prompts on *commands*. acceptEdits covers seven filesystem commands and nothing else; a build, a test run, or a git push still prompts. Named permissions.allow rules solve that directly.
Example
Start a session with edits pre-approved:
claude --permission-mode acceptEditsMake it the default for a project in .claude/settings.json:
{
"permissions": {
"defaultMode": "acceptEdits"
}
}Give Claude a second directory to treat as in-scope:
claude --permission-mode acceptEdits --add-dir ../shared-libWithout that flag, an edit to ../shared-lib prompts even in this mode.
Common mistakes
Reading it as "approve everything". It approves edits and seven filesystem commands. A curl, an npm install, or a git commit still prompts.
Forgetting the scope boundary. The mode is defined by *where*, not just *what*. An mv inside the project runs; the same mv targeting a path outside it asks.
Expecting it to touch protected paths. Writes to .git, .claude, and the rest of the protected set prompt in this mode. bypassPermissions writes them, and auto hands them to the classifier instead of you.
Setting it as a project default and forgetting. Every future session in that project starts with edits pre-approved, including ones you open months later for unrelated work.