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 — other shell commands, paths outside that scope, 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 — LANG=C, 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. Three things still prompt:
- paths outside that scope
- writes to protected paths —
.git,.claude,.vscode,.ideaand a few
others, the directories that hold repository state and Claude's own config
- 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. It covers ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, and read-only forms of git. 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.
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. Only bypassPermissions lifts that.
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.