Daily harness signal

Anchor permission at the subcommand

August 26, 2026 · JST One fresh finding Claude Code · Bash permissions · release gate
Claude Code now warns when Bash allow rules place a wildcard before the subcommand. Treat that warning as a failed permission migration: the rule authorizes more behavior than its wording suggests.
01 · Fresh · source date 2026-08-25

Make the operation the fixed prefix

Use when: a Claude Code project, user, managed, or local settings layer contains a Bash allow pattern whose first * appears before the operation-bearing subcommand—for example Bash(git * main), Bash(* --version), or any rule that pins only a trailing branch, target, or flag. This is most urgent in unattended or Auto mode sessions, where an overbroad allow can remove the prompt you expected to be the control.

Action: require Claude Code 2.1.246 or later so affected allow entries surface at startup. Open /permissions, inspect every warning, and replace each pre-subcommand wildcard with separate rules anchored through the intended subcommand. If the intent is read-only Git history, replace Bash(git * main) with Bash(git log * main); add Bash(git diff * main) only if diff is also intended. Do not silence the warning by broadening to Bash(git *). Keep push, merge, reset, clean, and other mutations outside the allow list; enforce irreversible operations again at the repository or server boundary.

Acceptance check: in a disposable repository, start a new 2.1.246 session and require zero wildcard-before-subcommand warnings. With only Bash(git log * main) allowed, git log --oneline main must run without a permission prompt. The read-only counterexample git -c core.fsmonitor= diff main must not inherit that allow and must enter the normal prompt/classifier path. Inspect the transcript and effective permission list, not the agent’s explanation. Fail the rollout if either the warning remains or the counterexample is auto-allowed by that rule.

Evidence: Anthropic’s official 2.1.246 changelog adds this exact startup warning. The current permissions reference explains why: * matches arbitrary text including spaces, and its matrix shows Bash(git * main) matching git merge main, git push origin main, and git -c core.fsmonitor= diff main. The same page instructs operators to place * after the subcommand. These are inspectable vendor semantics, not a marketplace or testimonial claim.

Caveat: 2.1.246 warns; it does not rewrite or block the rule. Subcommand-anchored string patterns also remain defense in depth, not a complete shell security boundary: global options, wrappers, variables, aliases, and interpreters can create semantically equivalent commands that a literal pattern does not express. Use sandboxing, synchronous hooks, Git hooks, and branch protection for effects that must remain impossible, and canary each execution plane separately.

Compact source notes

  1. Claude Code v2.1.246 (published 2026-08-25; inspected 2026-08-26). Official release artifact adding the pre-subcommand-wildcard startup warning.
  2. Claude Code permissions reference (retrieved 2026-08-26). Official matching matrix, subcommand-anchoring guidance, word-boundary behavior, and explicit examples of the overbroad rule’s match set.
  3. anthropics/claude-code issue #66176 (inspected 2026-08-26). Field reproduction and command-shape matrix for the complementary limitation: literal subcommand rules do not cover semantically equivalent global-option, environment-prefix, or wrapper forms.
  4. Method: anchor lens—vendor match examples and a negative-path canary; unity lens—permission intent must remain invariant across equivalent command representations. Confidence: Confirmed for the warning and documented match semantics; Likely for the field scope beyond the documented examples. Falsifier: on 2.1.246, a clean startup does not warn for Bash(git * main), or the documented counterexample is not authorized by that rule.