claude-code - 💡(How to fix) Fix [BUG] Heredoc as first argument bypasses pipe target permission checks [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48518Fetched 2026-04-16 06:57:57
View on GitHub
Comments
2
Participants
2
Timeline
9
Reactions
0
Author
Timeline (top)
labeled ×7commented ×2

Code Example

{
  "permissions": {
    "allow": ["Bash(cat:*)", "Bash(sort:*)", "Bash(head:*)"],
    "ask": ["Bash(some-script:*)"]
  }
}

---

echo test | some-script              # pipe target evaluated
cat /dev/null | some-script          # pipe target evaluated
cat --number <<'EOF' | some-script   # args before heredoc — pipe target evaluated
head -1 <<'EOF' | some-script        # args before heredoc — pipe target evaluated
sort --reverse <<'EOF' | some-script # args before heredoc — pipe target evaluated

---

cat <<'EOF' | some-script            # heredoc is first arg — pipe target NOT evaluated
sort <<'EOF' | some-script           # heredoc is first arg — pipe target NOT evaluated
head <<'EOF' | some-script           # heredoc is first arg — pipe target NOT evaluated
RAW_BUFFERClick to expand / collapse

Bug

When a heredoc marker (<<EOF or <<'EOF') is the first token after the command name, the permission system fails to evaluate pipe targets. An ask-listed command silently auto-allows when it appears after |.

Reproduction

Given these permission rules:

{
  "permissions": {
    "allow": ["Bash(cat:*)", "Bash(sort:*)", "Bash(head:*)"],
    "ask": ["Bash(some-script:*)"]
  }
}

Prompted (correct behavior)

echo test | some-script              # pipe target evaluated
cat /dev/null | some-script          # pipe target evaluated
cat --number <<'EOF' | some-script   # args before heredoc — pipe target evaluated
head -1 <<'EOF' | some-script        # args before heredoc — pipe target evaluated
sort --reverse <<'EOF' | some-script # args before heredoc — pipe target evaluated

Auto-allowed (bug — ask rule on pipe target skipped)

cat <<'EOF' | some-script            # heredoc is first arg — pipe target NOT evaluated
sort <<'EOF' | some-script           # heredoc is first arg — pipe target NOT evaluated
head <<'EOF' | some-script           # heredoc is first arg — pipe target NOT evaluated

Both quoted (<<'EOF') and unquoted (<<EOF) heredoc delimiters trigger the bug.

Expected behavior

The pipe target should be evaluated against permission rules regardless of whether the source command uses a heredoc.

Likely cause

The permission parser appears to stop analyzing the command at << when it is the first argument, treating everything after it (including | some-script) as heredoc content rather than continuing to parse the pipeline.

Impact

Any ask- or deny-listed command can be silently auto-allowed by piping from an allow-listed command with an immediate heredoc. This is a permission bypass — the user configured ask specifically to be prompted before execution, but never sees the prompt.

Related issues

  • #42426 — heredoc bypassing git commit permission checks (closed, same class)
  • #47752 — "Unhandled node type: pipeline" in permission prompt
  • #11932 — auto-approve patterns not matching heredoc commands
  • #30519 — meta-issue on permission matching

Environment

  • Claude Code on Linux (WSL2 Ubuntu 24.04)
  • Permissions configured in managed-settings.json (system-level)

extent analysis

TL;DR

The permission system can be fixed by modifying the parser to continue analyzing the command pipeline even when a heredoc marker is the first argument after the command name.

Guidance

  • Review the permission parser logic to ensure it correctly handles heredoc markers as the first argument and continues parsing the pipeline.
  • Verify that the parser can distinguish between heredoc content and subsequent pipeline commands.
  • Consider adding test cases to cover scenarios where heredoc markers are used as the first argument to ensure the permission system behaves as expected.
  • Investigate related issues (#42426, #47752, #11932, #30519) for potential insights into similar permission parsing problems.

Example

No code snippet is provided as the issue does not specify the exact implementation details of the permission parser.

Notes

The fix may require modifications to the permission parser's logic and potentially the grammar rules for handling heredocs and pipelines. The provided related issues may offer valuable context for understanding and addressing the problem.

Recommendation

Apply a workaround by avoiding the use of heredoc markers as the first argument after the command name until a proper fix is implemented, as this allows the permission system to correctly evaluate pipe targets.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The pipe target should be evaluated against permission rules regardless of whether the source command uses a heredoc.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING