Claude Code Desktop: "Always allow" is now the default button. How to revoke a rule you saved by accident

You press Enter on a Claude Code Desktop permission prompt thinking you approved one command, and the command becomes a permanent rule for the repository. Since version 2.37337.1 of the app (October 13, 2026), the prompt's main button is Always allow, and Allow once moved into the dropdown arrow next to it.

This guide shows where that rule is saved, how to delete the one you never meant to add, and how to stop risky commands from being allowed again by a reflex click. The interface change is reported in issue #102136 on the official repository, confirmed by users on macOS, Windows and Linux; the configuration side was checked against the official permissions documentation on October 19, 2026.

What changed in the Claude Code Desktop permission prompt?

The big button, the one that gets the reflex click and Enter, now saves a permanent rule. Approving just this once means opening the menu or using a different shortcut.

Option	Where it is	macOS shortcut	What it does
Always allow	Main button	⇧⌘↩	Saves an allow rule that applies to future sessions in the repository
Allow once	Dropdown arrow	⌘↩	Approves this run only, writes nothing
Allow and switch to Auto	Dropdown arrow	no shortcut reported	Approves and switches the session to Auto mode

The shortcuts above come from two independent reports in the issue, both on macOS. As of October 19, 2026 nobody has reported the equivalent shortcut on Windows or Linux. The same inversion had already been reported in issue #48550, which was closed as stale without a fix.

Where does Claude Code save the "Always allow" rule?

In .claude/settings.local.json at the root of the git repository, under permissions.allow. The documentation says a permanent approval for a Bash command or a WebFetch domain goes into that file and applies to future sessions anywhere in the repository, worktrees included.

There are exceptions: outside a git repository, when the repository root is your home folder, or on Windows, the file stays in the folder where the session started, next to .claude/settings.json. The Desktop app reads the same settings files as the CLI, according to the Desktop documentation.

One user reported in the issue that, in a single session, the main button wrote these two rules:

{
  "permissions": {
    "allow": [
      "Bash(gh api *)",
      "Bash(python3 -I -c ' *)"
    ]
  }
}

The first one allows any gh api call, including the ones that write to GitHub. That is why it is worth checking the file after any Desktop session.

How do you see and delete rules you saved by accident?

Open the file and look for the rules you did not choose. From the repository root:

cat .claude/settings.local.json

If you have jq installed, list just the allowed rules:

jq '.permissions.allow' .claude/settings.local.json

Delete the lines you do not want, save the file, and you are done. If you prefer a UI, open Claude Code in the terminal inside the same repository and run:

/permissions

The dialog lists every rule with the file it comes from, and you remove whichever you want. The documentation says the change applies from the next tool call, even while the agent is working.

.claude/settings.local.json does not end up in your commit: Claude Code adds the file to your global git excludes the first time it creates it. So a wrong rule does not leak to your team, but it does not show up in git diff either. You only find it if you open the file.

How do you stop a risky command from being allowed again?

Create ask rules for the commands you always want to approve by hand. The documentation sets the evaluation order as deny, then ask, then allow: an ask rule that matches the command brings the prompt back even when an allow rule for it exists, in any file.

Put them in your user file, ~/.claude/settings.json (on Windows, %USERPROFILE%\.claude\settings.json), so they apply to every project:

{
  "permissions": {
    "ask": [
      "Bash(python3 *)",
      "Bash(gh api *)",
      "Bash(git push *)",
      "Bash(psql *)"
    ]
  }
}

If the file already exists, merge the ask key into its existing permissions block without deleting the rest. Swap the list for the commands that touch databases, the network or production in your daily work.

For anything that should never run, use deny instead of ask. Deny beats everything, and an allow rule cannot carve an exception out of it.

Check that the guard works

In Desktop, ask the agent to run a command from the list, for example python3 -c "print(1)". The permission prompt has to show up even if .claude/settings.local.json still has an allow rule for python3. If it does not, open /permissions in the terminal and check whether the ask rule was loaded.

Isn't an ask rule for everything overkill?

It is, and one of the comments on the issue makes exactly that point: listing hundreds of commands under ask does not scale. The ask rule is for the short list of things that can do damage. For the rest, the habit that works is the Allow once shortcut (⌘↩ on macOS) and a quick look at .claude/settings.local.json at the end of the day.

Has Anthropic fixed it?

Not as of October 19, 2026. Issue #102136 is still open, with users asking for Allow once to be the main button again or for a setting to choose the default. Until a version changes that, the main button keeps writing rules.