Guide

Approve Claude Code without switching terminal windows

Q: How do I stop Claude Code asking permission for every command?

Add durable allow rules to your settings file. A rule like Bash(npm run test:*) in the permissions allow list means that command never prompts again. Claude Code can write these for you: when a prompt appears, choose the option that always allows, and the rule is written into the project's local settings.

Every permission prompt costs you a context switch, and the cost is not the click - it is finding the window again afterwards. There are two honest fixes and they stack: prompt less by telling the agent what it may always do, and answer the prompts that remain without leaving what you are doing. This guide covers both, in that order.

Applies to Claude Code on macOS

Why this hurts more than it should

A permission prompt is a blocking question in a window you are not looking at. So the interruption is not the two seconds of reading the command. It is the minutes between the agent stopping and you noticing, plus the reload cost of getting back to whatever you were doing. Run three sessions at once and the pattern becomes a loop: check, check, check, in case one of them is stuck.

Cutting that down has two independent levers. Fewer prompts is the first and it is free. Answering faster is the second.

Lever one, part one: the permission mode

Claude Code has a permission mode that governs how eagerly it asks. Shift+Tab cycles through them mid-session, and the current one is shown in the status line.

Default. Asks before each new kind of action. This is the mode to stay in for anything touching a repo you care about.
Plan mode. The agent may read and reason but may not edit files or run commands. Useful at the start of a task: let it produce the plan without any prompt at all, approve the plan once, then let it work.
Accept edits. Stops asking before file edits while still asking about other tools. Good for a branch you are prepared to throw away, uncomfortable anywhere else.
Bypass permissions. Skips the checks. Only sane inside a container or a VM you can discard, and it is the one mode where the phrase "it deleted the wrong thing" stops being hypothetical.

Plan mode is the underrated one. A large share of the prompts in a session come from the exploratory phase, and plan mode removes all of them by design.

Lever one, part two: an allowlist that fits your project

The durable fix is telling Claude Code which specific things it never has to ask about. These live in the permissions block of a settings file, and they are pattern-matched against the tool call:

// .claude/settings.json - committed, reviewed like code
{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Read(src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)"
    ]
  }
}

Three files can hold these, in increasing specificity: ~/.claude/settings.json for you personally, .claude/settings.json for the project and everyone on it, and .claude/settings.local.json for the things that are yours alone and should stay out of git.

You rarely need to write them by hand. When a prompt appears, one of the answers is the durable one: allow this always. Choosing it writes the rule into the project's local settings, .claude/settings.local.json, for you. The trick is to actually choose it for the commands you know you will approve fifty more times, instead of pressing plain yes on autopilot.

Keep the rules narrow. Bash(npm run test:*) removes noise. An unscoped shell rule removes the permission system. The point of an allowlist is to spend your attention on the calls that deserve it, not to stop paying attention.

Deny rules are worth writing too, and they are stronger than allow rules. A deny entry for destructive patterns holds even in a session where you got sloppy with the mode.

Lever two: the prompts that should still exist

After a good allowlist, what is left is exactly what you want left: the migration against staging, the force push, the file outside the project, the command you have never seen this agent run before. Those should interrupt you. The problem is not that they ask, it is where they ask - in a terminal tab that may be behind three windows on another Space.

Notifications are the usual answer and they are half of one. A banner tells you a session is waiting; you still have to go there. The notifications guide covers how to set those up properly, including a hook that posts a real macOS banner from any terminal.

Answering in place

The reason answering in place is possible at all is mechanical. A Claude Code permission hook blocks on a local Unix socket while it waits for a decision. Anything attached to that socket can send the decision back, and the prompt resolves where it stands.

CrewTower is a native macOS app built on exactly that. Every running session appears in the MacBook notch, the ones waiting on a human sort to the front, and the card carries the actual command. You press Allow or Deny there. Your terminal never comes forward and nothing is typed into it; there is deliberately no synthetic-keystroke path anywhere in the app.

It offers the same three answers the terminal does, which matters for this guide specifically: allow once; allow every permission request for the rest of this session, a grant CrewTower keeps itself rather than a rule in your settings; or, when Claude Code proposes a rule for the request, always - which has Claude Code write that rule into the project's local settings, the same kind of rule you would have written by hand above. So the fast path and the allowlist are the same action.

Destructive shell commands are flagged on the card before you press anything, so a quick Allow stays a considered one.

Honest limits. What CrewTower can do for a session depends on what that agent exposes: a visible session does not imply it can answer that session's prompts. When an agent offers no decision channel, the fallback is Jump, which focuses the exact terminal window, tab or split pane rather than just the application. Jump needs macOS Accessibility permission in the terminals where finding the tab takes it, such as Ghostty and Alacritty; answering from the notch never does.

It is $9.99 once for one Mac, no subscription, macOS 15 or later. It speaks natively to Claude Code, Codex, Cursor, Gemini CLI, Qwen Code and opencode.

The order to do this in

Start tasks in plan mode. Approve one plan instead of twenty steps.
For a week, take the always option on every prompt you would obviously approve again. Your allowlist will write itself.
Add deny rules for the things nothing should ever do in this repo.
Only then decide whether the prompts that remain need a faster surface. If you run one session at a time, they probably do not.

Questions

How do I stop Claude Code asking permission for every command?

Add durable allow rules to your settings file. A rule like Bash(npm run test:*) in the permissions allow list means that command never prompts again. Claude Code can write these for you: when a prompt appears, choose the option that always allows, and the rule is written into the project's local settings.

What is the difference between the permission modes?

Default asks before each new kind of action. Plan mode lets the agent read and think but not change anything. Accept-edits mode stops asking before file edits while still asking about other tools. There is also a mode that bypasses permission checks entirely, which should only be used in a sandbox or a throwaway container.

Is it safe to allowlist commands?

It is safe in proportion to how narrow the rule is. A narrow rule encodes a decision you have already made repeatedly, such as a test or build command you run fifty times a day. A broad one hands over decisions you have not made yet, and an unscoped shell is the same as turning permissions off.

Where should project rules live, committed or local?

Commit anything the whole team would agree with, such as the test and lint commands. Keep personal shortcuts in .claude/settings.local.json so nobody inherits your risk tolerance.

Can I approve a request without focusing the terminal?

Yes. Claude Code's permission hook blocks on a local Unix socket while waiting for a decision, so an app attached to that socket can answer it. CrewTower does this from the MacBook notch: the prompt resolves in place, with no window switch and no keystroke sent.

Does answering from an external app send keystrokes to my terminal?

It does not have to. CrewTower answers over the socket the hook is already blocking on, so nothing is typed anywhere. Be wary of any tool that solves this by simulating keypresses into a window.

Does this work with several sessions at once?

Yes. Each running session gets its own card, and the ones waiting on a human come to the front, which is the part that removes the check-check-check loop. Keeping track of several agents covers the rest of that setup.

Answer where you already are

CrewTower puts the waiting session in the notch with the command on it. One price, one Mac, no subscription.

Get CrewTower for Mac

$9.99 once · macOS 15 or later