[BUG] Bash comments break permissions

Status Fixed / completed
Reported on v2.1.34
Maintainer reply ✓ Yes — bcherny
Activity 9 comments · opened Feb 28, 2026 · closed Apr 19, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Since a few days ago Claude Code sometimes adds comments to tool executions, like this:

# Check the diff
git diff ....

Even if the allowlist contains Bash(git:*), I need to manually approve.

The same happens if the comment is after the command, or if the command itself uses the # sign for whatever reason.

What Should Happen?

If Claude Code runs a command, it should not add comments around it, so that tools from the allowlist execute without manual approval.

Error Messages/Logs

Steps to Reproduce

This mostly happens when I try to let it do a large task autonomously, which involves lots of external tool calls, for example reworking a coding task from one approach to another, which involves heavy git work.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.34 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

9 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/11932
  2. https://github.com/anthropics/claude-code/issues/25441
  3. https://github.com/anthropics/claude-code/issues/29421

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

jnjaeschke · 6 months ago

The referenced issues look similar, but I don't think they are duplicates.

limoragni · 5 months ago

Same here. I had a very well polished allow list where for the most part I never had permissions prompted on commands I allowed in the past. Now I have a lot of isntances where I need to approve command that are arealdy whitelisted because of messages like: "Command contains a backslash before a shell operator (;, |, &, <, >) which can hide command structure"

It's very common for claude to run such commands, specially on explore agents, and it makes the process spammy. Would be great to maybe have a flag that allows to run such commands as long it matches with the criteria of the allowlist? Or maybe cleverly allow certain combination of commands, or whitelist read command that can be run after a pipe operator?

jfiorato · 5 months ago

Just run /code-review:code-review without full Bash permission (Bash(*)) or --dangerously-skip-permissions and be prepared to hit enter repeatedly every 5 seconds.

yurukusa · 5 months ago

Workaround: a PreToolUse hook can strip the comment lines before permission matching sees them.

{"hooks":{"PreToolUse":[{"matcher":"Bash","hooks":[{"type":"command","command":"path/to/comment-strip.sh"}]}]}}

The hook reads the command, removes leading # lines, and returns the clean command via updatedInput. Your Bash(git:*) allowlist then matches correctly.

Implementation: comment-strip.sh

Or install it with all safety hooks: npx cc-safe-setup

limoragni · 4 months ago

Is auto mode meant to prevent this issue? Can we have it on the MAX plan? I see it's only for the Teams plan? Honestly CC has become almost unusable, I'm sitting right now hiting yes on 4 parallel sub agents it's the worst experience.

bcherny collaborator · 4 months ago

Thanks for the report. This is fixed — the reporter was on v2.1.34, which predates both fixes.

  • v2.1.72 added a real shell parser that skips comment nodes, so leading/trailing # ... lines never reach rule matching.
  • v2.1.76 fixed the case where a # inside a quoted argument was tripping the compound-command check.

Verified on current main:

  • # Check the diff\ngit diff HEAD → matches as git diff HEAD
  • git diff HEAD # check → matches as git diff HEAD
  • echo "hello#world" → matches as echo "hello#world"

Please upgrade to v2.1.76+ and reopen if you still see it.

(The "backslash before a shell operator" complaint further down the thread is a separate intentional security check, not this bug.)

claude[bot] contributor · 4 months ago

This issue was fixed as of version 2.1.76.

github-actions[bot] · 4 months ago

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.