## Description Bash permission allowlist entries like `Bash(cut:*)`, `Bash(tr:*)`, `Bash(uniq:*)` fail to match when the command uses `<<<` (here-string) syntax, even though the command prefix is correct. ## Steps to reproduce 1. Add `Bash(cut:*)` to permissions in `settings.json` 2. Run a command without `<<<`: `cut --help` — auto-allowed 3. Run a command with `<<<`: `cut -d' ' -f1 <<< "hello world"` — prompts for permission ## Expected behavior Both commands start with `cut` and should ma

Permission matching fails for commands using <<< (here-string) syntax

Status Fixed / completed

Maintainer reply ✓ Yes — bcherny

Activity 6 comments · opened Mar 22, 2026 · closed Apr 8, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Description

Bash permission allowlist entries like Bash(cut:*), Bash(tr:*), Bash(uniq:*) fail to match when the command uses <<< (here-string) syntax, even though the command prefix is correct.

Steps to reproduce

Add Bash(cut:*) to permissions in settings.json
Run a command without <<<: cut --help — auto-allowed
Run a command with <<<: cut -d' ' -f1 <<< "hello world" — prompts for permission

Expected behavior

Both commands start with cut and should match Bash(cut:*).

Actual behavior

Only commands without <<< are matched. The here-string syntax causes the permission check to fail.

Affected commands

Any command using <<<, confirmed with cut, tr, and uniq. Piping via echo "..." | cut ... works as a workaround (matched by Bash(echo:*)).

View original on GitHub ↗

6 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

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

oameye · 6 months ago

Not a duplicate — this is specifically about <<< (here-string) syntax breaking permission matching, which is distinct from the suggested duplicates:

#37106 — 2>&1 (output redirects)
#34379 — # character
#32876 — parentheses ()

While all are in the same class of "shell special syntax breaks Bash permission glob matching", <<< is a different operator (here-string input redirection) and may need a separate fix depending on how the matcher is implemented.

Environment

Claude Code version: 2.1.81
OS: Fedora 43 (Linux 6.18.10-200.fc43.x86_64)
Shell: bash

yurukusa · 6 months ago

Workaround: Use pipe syntax instead of here-strings until this is fixed.

cut -d' ' -f1 <<< "hello world"
echo "hello world" | cut -d' ' -f1

The permission matcher parses the command prefix to check against your allowlist. <<< confuses the parser because it changes the command structure — the string after <<< gets treated as part of the command rather than input.
If you want to auto-approve the pipe variant, your Bash(echo:*) permission will match the full pipeline since echo is the first command.

yurukusa · 6 months ago

Workaround: Use pipe syntax instead of here-strings until this is fixed.

cut -d' ' -f1 <<< "hello world"
echo "hello world" | cut -d' ' -f1

bcherny collaborator · 6 months ago

Thanks for the report. This is fixed in v2.1.85.

In v2.1.81 the new shell parser (which handles <<< here-strings correctly) was still gated to internal builds only, so external users fell back to the legacy regex checks that tripped on <<<. v2.1.85 removed that gate — all builds now use the new parser.

Verified on current main: cut -d' ' -f1 <<< "hello world" with allow rule Bash(cut:*) returns allow. Please upgrade and reopen if you still see it.