Claude Code Auto-Accept Mode

Quick Answer

Auto-accept mode runs every Claude Code tool call with no approval prompts. Toggle with Shift+Tab twice from default mode. The risk is real: Claude can delete files, run dangerous shell commands, and make large edits without a human in the loop. Use it when you have a safety net: a clean test suite, PreToolUse hooks blocking rm and force-push, and a git worktree you can throw away. TLDR: safe for well-defined tasks in isolated branches, not for production or unfamiliar code.

Summary of the 8 safety guards

1. Comprehensive test suite that fails on regressions
2. PreToolUse hooks blocking rm -rf and direct main pushes
3. Clean git working tree so you can reset
4. Isolated worktree branch for the session
5. File writes restricted to project folder via hooks
6. No access to production secrets from session env
7. Notification hooks logging every action
8. Quick rollback plan (git reset or stash)

What auto-accept mode does

Claude Code in default mode asks for approval on every write and shell command. Auto-accept skips those prompts. Claude runs its tool calls start to finish. The only thing you do is send the initial prompt and wait for the result.

The upside is speed. A 20-step task that would normally take 2 minutes of clicking accept takes 30 seconds in auto-accept. The downside is that you lose the safety of per-step review. A rogue tool call, a misinterpreted prompt, or a buggy agent response can all cause damage before you notice.

How to enable auto-accept

From an active session, press Shift+Tab twice from default mode. The first press cycles to plan mode. The second press cycles to auto-accept. A third press returns to default.

You can also configure auto-accept in .claude/settings.json by setting permissionMode to acceptEdits or bypassPermissions. Do this only for projects where the other safety guards are already in place.

The real risks

3 categories of mistakes matter.

First, file deletion. Claude can run rm via the Bash tool. A prompt like "clean up unused files" taken too literally might delete things you care about.

Second, destructive git operations. Force push to main, reset to a wrong commit, or deleting a branch. These are hard to reverse and sometimes impossible.

Third, shell commands with side effects. Dropping a database table, sending an email, posting to a webhook, running a migration. Any command that touches external state is dangerous in auto-accept.

All 3 are preventable with hooks. None are handled automatically.

The hooks-first approach

PreToolUse hooks are the primary safety mechanism for auto-accept mode. They run before every tool call and can block the call based on custom logic.

A minimum hook set for auto-accept should block 5 things.

1. Any rm -rf command
2. Any git push --force to main or master
3. Any git reset --hard that loses uncommitted work
4. Writes to files outside the project folder
5. Writes to files matching .env, .pem, or similar secret patterns

You configure hooks in .claude/settings.json under the hooks field. The shell scripts live in .claude/hooks/ and exit non-zero to block a tool call.

Here is the shape of a typical hook.

#!/bin/bash
# .claude/hooks/block-rm-rf.sh
if echo "$CLAUDE_TOOL_ARGS" | grep -q 'rm -rf'; then
  echo "Blocked: rm -rf is not allowed" >&2
  exit 1
fi
exit 0

With hooks in place, auto-accept becomes reasonable for a wide range of tasks.

When auto-accept is appropriate

4 conditions to check before turning it on.

The task is well-defined. You know what success looks like and can describe it in one paragraph. If the goal is fuzzy, Claude will interpret it creatively, and creativity without supervision goes wrong fast.

The codebase is clean. Tests pass on main. The working tree is clean. There are no pending uncommitted changes that could get corrupted.

The actions are reversible. Git commits can be reset. File edits can be stashed. Database changes cannot. Auto-accept works best when the worst case is a wasted hour, not a corrupted production database.

The hooks are active. Verify with /status that the hooks you expect are loaded.

When NOT to use auto-accept

5 scenarios where auto-accept is the wrong choice.

Production servers. Never run auto-accept in an environment with production credentials. One misread prompt and you are explaining an outage.

Unfamiliar code. If you do not know the codebase, you cannot judge the diff in a glance. Stay in default mode until you build intuition.

Tasks that touch secrets. Auto-accept sessions should never have access to API keys for critical third-party services.

Long multi-hour sessions. Context drift over 50k tokens makes the agent less reliable. Safer to run in default mode when the session is long.

First use on a new project. Spend the first few sessions in default mode to verify Claude handles your conventions correctly before trusting it with no human in the loop.

Recovery from mistakes

Assume mistakes will happen eventually. The 3 recovery tools are git, your IDE, and your backups.

Git reset hard: rolls back the working tree to the last commit. Useful if Claude committed something wrong.

Git stash: saves uncommitted changes and restores a clean tree. Useful if Claude made edits that you do not want to keep.

IDE undo: most editors keep a local history of file changes. VS Code Timeline feature or JetBrains Local History can recover recent edits even after a git reset.

The recovery plan for auto-accept is: always commit before you start, always work in a branch, and always have a clean starting point you can reset to.

Combining with worktrees

The safest auto-accept pattern is running in an isolated git worktree. Create a worktree on a new branch, dispatch the auto-accept work there, and review the resulting branch before merging.

This cuts the blast radius to a single branch. If auto-accept goes wrong, you delete the branch and try again. The main working tree is untouched.

Team policy considerations

Auto-accept policy is a real team discussion. 3 common positions.

Allow for everyone: any team member can enable auto-accept on any task. Risky but fast.

Allow in worktrees only: team members can run auto-accept in isolated worktrees but never in the main checkout. Balances safety and speed.

Allow for senior only: junior developers stay in default mode, senior developers can use auto-accept when they judge it safe. Protects against the failure mode of an inexperienced developer missing a destructive command.

Most teams land at position 2. Worktrees make the blast radius small enough that the occasional mistake is not a crisis.

Monitoring auto-accept sessions

2 hook patterns help with observability.

First, log every tool call to a file. A PreToolUse hook that writes to ~/.claude/logs/.log gives you a replay of every action Claude took. Invaluable when debugging a session that went wrong.

Second, notify on sensitive commands. A PreToolUse hook that pings Slack when Claude runs git push, migrate, or deploy gives you real-time awareness of the consequential actions without blocking them.

Neither hook slows down the session meaningfully. Both pay for themselves the first time something goes wrong.

A practical auto-accept recipe

Here is a safe starting point you can use today.

Before the session: create a worktree on a new branch. Verify tests pass. Verify hooks are loaded via /status. Verify no production credentials are in the session env.

During the session: send a clear prompt describing the end state. Toggle to auto-accept. Monitor the terminal log, not every action, but enough to notice if Claude goes off the rails.

After the session: review the resulting diff in your IDE. Run the full test suite. If everything looks right, merge the branch. If not, delete the branch and try again with a refined prompt.

This recipe handles 90 percent of auto-accept use cases safely. The remaining 10 percent (production deploys, secret handling, destructive migrations) should stay in default or plan mode regardless.

A note on expectations

Auto-accept mode is a power-user feature. It pays off when the rest of your setup is mature. Teams that turn it on before investing in hooks, tests, and worktree discipline usually end up in trouble within the first week. Teams that invest in those guardrails first, then turn on auto-accept, see a 2x to 3x speedup on routine tasks with no safety regression. The question is not whether auto-accept is good or bad. The question is whether your codebase and workflow are ready for it. If tests pass reliably, hooks block the worst categories of mistakes, and worktrees contain any damage, auto-accept delivers on its speed promise without hurting quality. If any of those conditions are missing, start with default mode and earn your way toward auto-accept as the safety net gets stronger.