How do I stop getting permission prompts every few seconds in Claude Code?

First check which permission mode you're in: press Shift+Tab and watch the status bar. Then pre-approve the commands you trust, either from the prompt itself ("Yes, and don't ask again"), with /permissions, with /fewer-permission-prompts, or by writing allow rules in settings.json. Auto mode and the Bash sandbox's auto-allow mode remove most routine prompts. --dangerously-skip-permissions exists, but Anthropic's docs reserve it for isolated containers and VMs.

All of this comes from Claude Code's documentation as of October 2026.

Step 1: find out which mode you're in

Claude Code has six permission modes. The status bar shows the active one. Shift+Tab cycles through default, acceptEdits, plan and auto; bypassPermissions joins the cycle only if you started with it enabled, and dontAsk is never in it (set it with --permission-mode dontAsk).

With Claude Code v2.1.283 or later, auto mode is the built-in starting mode for interactive terminal and VS Code sessions. If you get a prompt every few seconds, you're probably in Manual mode: an older version, an organization that turned auto mode off, a model that doesn't support it, or a defaultMode set somewhere.

To choose the starting mode yourself, use the flag or the setting:

claude --permission-mode acceptEdits

{ "permissions": { "defaultMode": "acceptEdits" } }

One trap: "auto" and "bypassPermissions" don't take effect from a project's .claude/settings.json or .claude/settings.local.json. Put "auto" in ~/.claude/settings.json.

Step 2: pre-approve what you trust

From the prompt

When a Bash prompt offers "Yes, and don't ask again", the rule is saved to .claude/settings.local.json at the root of the git repository and applies to future sessions there, worktrees included.

With /permissions

/permissions opens a dialog to view, add and remove allow, ask and deny rules by scope. Its alias is /allowed-tools.

With /fewer-permission-prompts

/fewer-permission-prompts

This bundled skill scans your transcripts for common read-only Bash and MCP tool calls and adds a prioritized allowlist to the project's .claude/settings.json. Read what it adds before committing it.

In settings.json

Rules live in ~/.claude/settings.json (you, every project), .claude/settings.json (the team, committed) or .claude/settings.local.json (you, this project):

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm -rf *)"
    ]
  }
}

How the rules behave:

• Order is deny, then ask, then allow. The first match wins, and a narrow allow rule can't carve an exception out of a broad deny.
• Put the * after the subcommand. Bash(git log *) allows only git log. Bash(git *) allows every git command. Claude Code warns at startup about an allow rule with a * before the subcommand.
• Rules match command text. Bash(git push *) doesn't match git -C . push. Treat rules as convenience, not a security boundary.

For a single run, --allowedTools does the same from the command line:

claude --allowedTools "Bash(npm run test *)" "Read"

Step 3: let the sandbox replace the prompt

On macOS, Linux and WSL2, Claude Code can run Bash commands in a sandbox that restricts filesystem and network access at the OS level. Run /sandbox and pick auto-allow mode: commands that run inside the sandbox are approved without a prompt. Deny rules still block, and ask rules that name a command still prompt. The docs list "Manual mode plus the Bash sandbox in auto-allow mode" as the setup for fewer prompts without a classifier.

What about --dangerously-skip-permissions?

It is equivalent to --permission-mode bypassPermissions. What the docs say about it:

• It skips permission prompts, including writes to protected paths such as .git and .claude.
• It offers no protection against prompt injection or unintended actions. Only your deny rules still stand between the agent and your machine.
• Allow rules have no effect in this mode. Deny rules still apply.
• The docs' setup table pairs it with a required isolation boundary (a container, a VM or the sandbox runtime) and a non-root user on Linux and macOS.
• The warning reads: use it only in isolated environments like containers, VMs or dev containers without internet access, where Claude Code can't damage your host.

On your own machine, with your SSH keys, cloud credentials and other repositories one cd away, that boundary doesn't exist. If you want fewer prompts on your laptop, auto mode, allow rules and the sandbox are the documented routes. To make sure nobody on a team uses bypass mode, set permissions.disableBypassPermissionsMode to "disable", usually in managed settings.

Limits of these fixes

• Auto mode isn't a guarantee. The docs say it reduces prompts but doesn't guarantee safety, and recommend it for tasks where you trust the general direction.
• Broad allow rules are broad. Bash(npm run *) lets the agent run every script in package.json, whatever those scripts do.
• Some prompts stay. Ask rules, protected paths in some modes, and a few actions no mode auto-approves still stop the agent.
• Each prompt still blocks a session. With several sessions open, the one that asks sits idle until you notice it.

With Kanbell

Kanbell doesn't change Claude Code's permissions. It deals with the last limit: the prompt you don't see.

• When an agent waits on a permission or a question, an orange dot appears in the project window, the menu bar and the overview, and Kanbell sends a macOS notification.
• ⌘⇧J jumps to the next agent that is waiting.
• For Claude Code, Kanbell shows whether the wait is a question or a permission. Codex CLI and Gemini CLI permission waits are detected too.

Kanbell is a macOS app for Apple Silicon, with real terminals in panes and tabs, one window per project. There is no account and no Kanbell server.