[BUG] Wrong command is reported in "don't ask again for" in "This command requires approval"

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/11007
2. https://github.com/anthropics/claude-code/issues/16180

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Possible duplicates are not relevant. The second command is not executed and the first one seems related but is closed.

There's also an inconsistency about spaces vs colons that happens in these cases.

I have Bash(git log *) in my allow list. Claude has no trouble with simple git log ... commands.

But if Claude tries to do

git log main..HEAD --format="%H %s" | while read hash msg; do … git diff-tree … done

it raises this permissions check:

git log main..HEAD --format="%H %s" | while read hash msg; do echo "=== $hash $msg ==="; git diff-tree --no-commit-id -r --stat $hash; echo; done
   Show files changed in each commit since main

 Do you want to proceed?
 ❯ 1. Yes
   2. Yes, and don’t ask again for: git log:*
   3. No

https://github.com/anthropics/claude-code/blob/main/plugins/plugin-dev/skills/command-development/references/frontmatter-reference.md suggests the colon, which is consistent with the message, but it doesn't explain what the colon means. Is it a case of bash -c separating the command from the arguments?

Root Cause Analysis

I reproduced this bug by analyzing how tree-sitter-bash (the parser Claude Code uses for bash command analysis) builds the AST for compound commands.

Why It Happens: Bash Operator Precedence in the AST

The key insight is that | (pipe) has higher precedence than || and && in bash. This means tree-sitter-bash parses:

hyprctl clients -j | python3 -c "..."

as:

pipeline
  command ("hyprctl")
  command ("python3")

But for commands with redirects + logical operators + pipe:

wg show 2>/dev/null || wireguard-go --help 2>&1 | head -5

the AST becomes:

pipeline
  redirected_statement          ← NOT a "command" node!
    list
      redirected_statement
        command ("wg show")     ← The real first command (buried inside)
      command ("wireguard-go")
    file_redirect (2>&1)
  command ("head")              ← The only direct "command" child of pipeline

The Bug

The prefix extraction algorithm appears to search for the first direct child of type command inside a pipeline node — without recursing into wrapper nodes like redirected_statement or list.

Since redirected_statement is not a command type, it gets skipped. The algorithm then finds head (or tail, grep, python3) — which is the right side of the pipe — and uses that as the prefix.

Verified with tree-sitter-bash

I confirmed this AST structure using web-tree-sitter@0.24.7 + tree-sitter-wasms:

const Parser = require('web-tree-sitter');
await Parser.init();
const parser = new Parser();
const lang = await Parser.Language.load('tree-sitter-bash.wasm');
parser.setLanguage(lang);
const tree = parser.parse('wg show 2>/dev/null || cmd --help 2>&1 | head -5');
// Print AST → confirms pipeline → redirected_statement → list → command structure

| Command | Prefix shown | Should be |
|---------|-------------|-----------|
| wg show 2>/dev/null \|\| cmd 2>&1 \| head -5 | head:* | wg:* |
| bun init -y 2>/dev/null && bun add ... 2>&1 \| tail -5 | tail:* | bun:* |
| cat file 2>/dev/null \| head -5 | head:* | cat:* |
| ls -la 2>&1 \| grep pattern | grep:* | ls:* |
| git log ... \| while read ... (from @jamesarosen's comment) | while:* or similar | git:* |

Suggested Fix

When traversing a pipeline node, if a direct child is not a command/declaration_command, the algorithm should recurse into it rather than skip it. This way redirected_statement → list → command chains are properly followed, and the first real command in the pipeline is found.

Pseudocode:

find_command(node):
  if node.type in {"command", "declaration_command"}: return node
  if node.type in {"pipeline", "redirected_statement"}:
    for child in node.children:
      if child.type in {"command", "declaration_command"}: return child
      found = find_command(child)   // ← THIS RECURSION IS MISSING
      if found: return found
    return null
  // default: recurse into all children
  for child in node.children:
    found = find_command(child)
    if found: return found
  return null

TDD Validation

I built a test suite (13 tests, node:test + real web-tree-sitter parser) comparing the current behavior vs the fixed algorithm. All 13 pass — the fix resolves the bug without breaking simple commands, &&/|| lists, semicolons, or declaration_command (export, local). Happy to share the repo if helpful.

TDD test suite for this bug (13 tests, all green): https://gist.github.com/fedosov/b155ad5b0fe016375dcd65322147dd2a

npm install && npm test

Tests use web-tree-sitter + tree-sitter-bash to parse real bash commands and compare the current algorithm (reproduces the bug) vs the fixed one.

I'm seeing the opposite thing, for example somecmd | tail -n 3 will keep asking me to allow tail even though tail is already allowed. It's very very frustrating because claude keeps bothering me incessantly. I'm not sure if it's because somecmd isn't allowed or what, but over and over again, with many different commands that | tail ... will ask to be allowed (and also commonly for grep).

<img width="1125" height="398" alt="Image" src="https://github.com/user-attachments/assets/8643de9c-77f8-4316-9fbb-7d3591158120" />

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

The bug is still there. See the comment above for a solution. Please reopen the issue.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.