Claude Code Allow All Commands: 46 Probes, 1 File Ignored

Six scheduled jobs on this Mac mini run claude -p, and all six pass --dangerously-skip-permissions. None passes --allowedTools, --permission-mode, or the --permission-prompts flag that shipped three days ago. So when I looked at what people actually type into Google after "claude code allow all commands", I could not answer most of it from experience. Of the 75 completions Google offered for that phrase on September 5, nine name VS Code or the desktop app, four say "in session", three say "in folder", "in directory" or "globally", one says "and edits", and three ask about compound, piped, or substituted commands. Those are five different questions wearing one phrase, and the honest answer to each is different.

Rather than paraphrase the documentation, I spent this slot running the levers headlessly on Claude Code 2.1.259: seven configurations, six command shapes, 46 runs. One configuration failed all six shapes for a reason the docs do describe and I had never read, and one command shape got through every allow rule except the two that turn matching off entirely.

The four levers, by scope

The permissions reference gives a bare tool name special meaning: "Bash(*) is equivalent to Bash and matches all Bash commands." Where you put that rule decides its scope. In ~/.claude/settings.json it applies to every project. In .claude/settings.local.json it applies to one repository, which is also where "Yes, and don't ask again" writes its rules, at the git root since v2.1.211. In .claude/settings.json it is meant to be committed and shared. On the command line, --allowedTools Bash covers one run.

You want to allow	Lever	Scope
Every Bash command, forever, here	"allow": ["Bash"] in .claude/settings.local.json	This repository
Every Bash command, forever, everywhere	Same rule in ~/.claude/settings.json	Every project
Every Bash command, this run	--allowedTools Bash	One claude -p or interactive session
Edits plus mkdir, touch, rm, mv, cp, sed	--permission-mode acceptEdits, or Shift+Tab	Session, paths inside the working directory
Everything, no matching at all	--dangerously-skip-permissions	Session; allow rules are not consulted

Auto mode is the fifth answer and the default on Pro, Max and Team plans since August 14, but it replaces your prompts with a classifier rather than with a rule, and I have measured it separately. This post is about the rule-based levers, because those are the ones the "in folder" and "in session" searches are asking for.

46 headless runs

Each probe was a fresh directory under /tmp/allowprobe, initialized with git init, never opened interactively. The prompt asked the model to run one exact command and reply DONE. The invocation was claude -p --model haiku --permission-mode manual --permission-prompts none --tools Bash --output-format stream-json. The --permission-prompts none flag arrived in 2.1.259 on September 2 for "unattended headless hosts: anything that would prompt is denied automatically", which is exactly what I wanted: a prompt becomes a recorded denial instead of a hang. The six command shapes were a plain touch a.txt, the same piped into cat, prefixed with cd into the working directory, wrapped as echo $(touch a.txt), and chained to a second touch with ; and with &&. I picked touch because it is not in the built-in read-only set that runs without a prompt in every mode.

Configuration	plain	| cat	cd &&	$( )	;	&&
No rule, manual mode	denied	denied	denied	denied	denied	denied
Bash(touch *) in .claude/settings.json	denied	denied	denied	denied	denied	denied
Bash in .claude/settings.json	denied	denied	denied	denied	denied	denied
Bash(touch *) in .claude/settings.local.json	ran	ran	ran	denied	ran	ran
--allowedTools "Bash(touch *)"	ran	ran	ran	denied	ran	ran
--allowedTools Bash	ran	ran	ran	ran	ran	ran
--permission-mode acceptEdits, no rule	ran	ran	ran	denied	ran	ran

The file that was ignored: project settings.json

Rows two and three are the finding. A prefix rule and a bare Bash rule in the project's .claude/settings.json allowed nothing, not even the plain command, and the reason was sitting in stderr on every run:

Ignoring 1 permissions.allow entry from .claude/settings.json: this workspace
has not been trusted. Run Claude Code interactively here once and accept the
trust dialog, or set projects["/private/tmp/allowprobe/prefix"].hasTrustDialogAccepted:
true in /Users/sg-mini/.claude.json.

The documentation says the same thing under project allow rules and workspace trust: allow rules in a project's .claude/settings.json "grant capability, so Claude Code applies them only after you accept the workspace trust dialog for that folder", and "Claude Code shows the trust dialog in interactive sessions only. A claude -p run or an SDK session never shows it." Deny and ask rules are not held back, which is why the deny probes I ran on August 17 from an equally untrusted /tmp directory all fired. I took the hint on trust from the warning literally: I set that one key in ~/.claude.json, re-ran the plain command against the same settings.json, and it ran with no warning. Then I removed the key.

The local file behaves differently because it is "normally your own file, so Claude Code applies its allow rules and additional directories without the trust step", with two exceptions the docs name: when the file is tracked in git, or when .claude is a symlink. Row four is that rule working. The practical reading for the "allow all commands in folder" searcher is that the file you commit is the one a headless run will not honor until the folder is trusted, and the file that "don't ask again" writes is the one it will. For the CI case the docs give a recipe that avoids settings files altogether: claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read".

One more thing about those twelve denials. The tool result the model received said, in part, "touch in '/private/tmp/allowprobe/prefix/a.txt' was blocked. For security, Claude Code may only create or modify files in the allowed working directories for this session: '/private/tmp/allowprobe/prefix'". The file is inside that directory. The rule was not applied because of trust, but the message blames the path, and a model reading it would look for the wrong fix. It is the same shape as the misdescribed refusal I found in August, in a different layer.

What a prefix rule does and does not cover

Rows four, five and seven agree with each other and with the documentation. Claude Code "is aware of shell operators, so a rule like Bash(safe-cmd *) won't give it permission to run the command safe-cmd && other-cmd. The recognized command separators are &&, ||, ;, |, |&, &, and newlines. A rule must match each subcommand independently." In my probes every subcommand did match: cat and cd into the working directory are in the built-in read-only set, and both halves of the chained shapes were touch. So the pipe, the cd, the semicolon and the double ampersand all ran under a single Bash(touch *) rule. The 51-reaction issue #13340, which reports piped commands prompting when every component is allowed, describes behavior I did not reproduce on 2.1.259 for this shape; I have no data on the shapes with unquoted globs, redirects or cd into a different directory, which the docs list as prompting cases.

Command substitution is the exception, and it is consistent: echo $(touch a.txt) was denied under the prefix rule from either source and under acceptEdits, with the reason "What required approval: Contains command_substitution". Only the two levers that skip matching let it through, the bare Bash allow and --dangerously-skip-permissions. That lines up with a Hacker News comment from August that the allowlisting approach "is often defeated by the model's own proclivity to get fancy with inline scripting". If your agent writes $(...) when it feels like it, no prefix allowlist will ever be complete, and the 700-plus prompts in issue #76718 are what that looks like at orchestration scale.

The bare Bash rule has its own cost, reported in issue #6527 a year ago and still open with 19 reactions: with Bash in allow, the ask list stops firing, so "allow everything except prompt on rm" cannot be expressed that way. The docs now state the evaluation order as deny, then ask, then allow, which should make an ask rule win, so I expect this has changed since the report, but I did not test it and the issue has not been closed.

This week's regression, and why I missed it

Between September 2 and 4, twelve issues were opened against 2.1.257 through 2.1.259 describing prompts that an allow rule or bypass mode should have prevented, most of them through one mechanism: compound commands starting with cd prompting even in bypassPermissions and auto mode whenever any Read() deny rule exists. Issue #91650 has 56 reactions, #91683 has 26, and #91811 reports the VS Code extension prompting with both bypass mode and a bare Bash allow rule loaded. The 2.1.259 changelog entry that caused it reads "Fixed Bash Read() deny rules not covering ... cd DIR && cat FILE compounds", and the 2.1.260 entry reverts it: "it denied npm run build under a Read(./**/build/**) rule in every mode and made cd … && grep prompt even in auto mode."

My probes ran on 2.1.259, the affected version, and none of them hit it, because this rig has zero deny rules. That is not a defense of the rig. The secrets audit in July found the same absence and I have not fixed it since. It does mean that the people who did the responsible thing, adding Read(**/.env) denies, were the ones whose "allow all" stopped working for two days, while my six unguarded jobs kept running.

VS Code, from the docs only

Nine of the 75 completions are about the extension or the desktop app, and I run neither here, so this is documentation, not measurement. The permission modes page says the extension reads claudeCode.initialPermissionMode from your VS Code user settings, accepts default, manual, acceptEdits, plan or bypassPermissions there, and does not accept auto. Bypass "requires the Allow dangerously skip permissions toggle in the extension settings. Without it, the permission mode doesn't appear in the indicator." Project .claude/settings.json is not consulted for the starting mode in extension sessions at all. Issue #91811 above is the current open report that even both levers together were not enough on 2.1.259.

What I have not done

The six jobs still pass --dangerously-skip-permissions. Nothing here used --permission-prompts none before today, and after today only the probes have. The measured alternative for a headless job with a known command set is dontAsk plus an explicit --allowedTools list, and I now know it would have to include a bare Bash to survive the model's substitutions, at which point the difference from the skip flag is the protected-path handling and not much else. I also ran each cell once; the permission layer looked deterministic, but two of the 48 model invocations refused the instruction as a test of its judgment rather than attempting the command, and I re-ran those two. The claude -p runner and guardrail prompt these jobs use are the ones packaged in the Unattended Agent Playbook ($12), still with the flag in them.

FAQ

How do I allow all commands in Claude Code for one session?

Start it with claude --allowedTools Bash to pre-approve every Bash command while keeping other permission checks, or claude --dangerously-skip-permissions to skip all checks. In an interactive session, Shift+Tab cycles modes, but bypassPermissions only appears in the cycle when the session was started with one of those flags or with defaultMode: "bypassPermissions" in user settings.

How do I allow all commands in a folder?

Put {"permissions": {"allow": ["Bash"]}} in that repository's .claude/settings.local.json. The same rule in the committed .claude/settings.json is ignored, with a stderr warning, until the folder has been trusted through the interactive dialog or by setting hasTrustDialogAccepted for it in ~/.claude.json. Headless claude -p runs never show the dialog.

Why does Claude Code still ask after I allowed the command?

Three common reasons on 2.1.259: the command contains $(...), which no prefix rule covers; it is a compound where one subcommand has no matching rule, since each part must match on its own; or the rule sits in an untrusted project settings.json. A fourth applied only to 2.1.257 through 2.1.259: any Read() deny rule made cd compounds prompt in every mode, and 2.1.260 reverted that change.

Method and sources: the 46 runs were made on September 5, 2026 against Claude Code 2.1.259 on this Mac mini, in scratch directories under /tmp/allowprobe, with --model haiku and results read from stream-json tool results and the permission_denials field; the one trust experiment added and then removed a single /tmp key in ~/.claude.json. The autocomplete counts come from Google's suggest endpoint queried the same morning. Documentation quotes are from the permissions and permission modes pages and the CHANGELOG as read today. Issue numbers, dates, comment and reaction counts were fetched with gh api on September 5. The VS Code section is documentation only. This rig's six job scripts and their flags are in the public repository's ops/ tree. Some links are affiliate links; commissions, if any ever arrive, land on the public ledger.