Bash Command Redirection Fails with `2>&1` is treated as if the `2` was a separate parameter

I've been seeing this regularly also, eg.

● Bash(cargo build --release --bin probe-rs 2>&1 | tail -20)
  ⎿  error: unexpected argument '2' found

Currently on 1.0.64 (Claude Code)

When I had Claude Code investigate this issue itself, it provided this URL through its search tools. Based on my somewhat unreliable memory, this wasn't a bug that existed from the beginning—it didn't start occurring until after a specific version release, did it?

I exported the conversation using /export and extracted the problematic command.

> `scpwiki_mirror/`の元のプロジェクトのパスを特定して。
  Gitのリカバリならコミットログも辿れるかな？ただのコピーなら、Gitでソース管理しているのにこ
  んな風に分ける必要性自体が理解できない。何か理由があるのだろうか。

● Bash(cd /home/ubuntu/git_recovery_backups/claude-scp-translation-hub_20250626_100615 && git
       log --oneline -10 2>/dev/null)
  ⎿  Error: Error

====

● Bash(cd /home/ubuntu/claude-scp-translation-hub && pwd && git log --oneline -3 2>/dev/null
      && echo "---" && ls -la scpwiki_mirror 2>/dev/null | head -5)
  ⎿  Error: fatal: ambiguous argument '2': unknown revision or path not in the working tree.
     Use '--' to separate paths from revisions, like this:
     'git <command> [<revision>...] -- [<file>...]'

     /home/ubuntu/claude-scp-translation-hub

====

✻ Thinking…

  動作しました。では正しいリダイレクトの方法を試します。

● Bash(find /tmp -maxdepth 1 -name "*.txt" 2>/dev/null -exec du -ch {} + | tail -1)
  ⎿  find: paths must precede expression: `2'

✻ Thinking…

  やはり同じエラー。findコマンドは2>/dev/nullを引数として解釈しようとしています。正しい方法を
  試します。

● Bash({ find /tmp -maxdepth 1 -name "*.txt" -exec du -ch {} + ; } 2>/dev/null | tail -1)
  ⎿  /bin/bash: line 1: {: command not found
     /bin/bash: line 1: }: command not found

✻ Thinking…

  bashで中括弧の前後にスペースが必要です。

● Bash((find /tmp -maxdepth 1 -name "*.txt" -exec du -ch {} +) 2>/dev/null | tail -1)
  ⎿  Error: /bin/bash: eval: line 1: syntax error near unexpected token `2'
     /bin/bash: eval: line 1: `( find /tmp -maxdepth 1 -name \*.txt -exec du -ch \{\} + ) 2 > 
     /dev/null < /dev/null | tail -1'

✻ Thinking…

  なるほど！問題が見えました。エラーメッセージを見ると：
  ( find /tmp -maxdepth 1 -name \*.txt -exec du -ch \{\} + ) 2 > /dev/null < /dev/null | tail
   -1

  2>が2 >として分割されています！これはBashツールの実装の問題のようです。リダイレクト演算子が
  正しく解析されていません。

From now on, I'll try adding the following line to ~/.claude/CLAUDE.md:

- NEVER use `2>/dev/null` or `2>&1` in Bash commands - this is a known tokenization bug that causes errors.

My memory and understanding is this is something introduced fairly recently. I'm pretty sure it used to work.

I created a bug report, but will append here instead:

Bug Report: Claude Code Bash Tool Incorrectly Parses stderr Redirection with Pipes

Summary

The Bash tool in Claude Code treats 2>&1 as literal arguments when used with pipes, instead of as stderr redirection.

Reproduction

1. Direct command (FAILS)

echo "test" 2>&1 | cat

Expected: test
Actual: test 2

2. With bash -c wrapper (WORKS)

bash -c 'echo "test" 2>&1 | cat'

Output: test ✅

3. Create and run this test script (WORKS)

cat > test-bug.sh << 'EOF'
#!/bin/bash
echo "Test 1: Direct in script"
echo "test" 2>&1 | cat

echo -e "\nTest 2: Command with stderr"
ls /nonexistent 2>&1 | head -1

echo -e "\nTest 3: npm with redirection"
npm --version 2>&1 | head -1
EOF

chmod +x test-bug.sh
./test-bug.sh

Output: Works correctly, showing stderr is properly redirected ✅

The Problem

| Command | Expected | Claude Bash Tool Output |
|---------|----------|------------------------|
| echo "test" 2>&1 \| cat | test | test 2 ❌ |
| ls 2>&1 \| head | (file listing) | ls: cannot access '2': No such file or directory ❌ |
| npm run build 2>&1 \| head | (build output) | Error: tries to run "vite build 2" ❌ |

Impact

• Cannot capture build output with errors: npm run build 2>&1 | tee build.log
• Cannot filter combined output: command 2>&1 | grep error
• Standard shell patterns fail unexpectedly

Workaround

Use bash -c:

bash -c 'npm run build 2>&1 | head -20'

Root Cause

The Bash tool appears to parse the command before passing to shell, incorrectly tokenizing 2>&1 as arguments rather than recognizing it as a redirection operator. This only happens when combined with pipes (|).

Environment

• Claude Code CLI
• Platform: Linux/WSL2
• Confirmed: 2025-08-06

Can confirm on v1.0.69 and v1.0.70 on Ubuntu 24.04.3.

I'll also confirm that this is a recent regression.

Only recently started seeing this within the last week or two. WSL1 ubuntu 22.04 with windows terminal

Until this bug is fixed, you can add this script to your project:

#!/bin/bash
# Simple wrapper script to work around bash tool stderr redirection bug
# Usage: ./scripts/run_with_stderr.sh command args...
exec "$@" 2>&1

and add these instructions to your CLAUDE.md:

## 🚨 CRITICAL: stderr redirects are broken in the Bash tool 🚨

**You can't use `2>&1` in your bash commands** -- your Bash tool will mangle the stderr redirect and pass a "2" as an arg, and you wont' see stderr. 

**Workaround**: Use the wrapper script: `./scripts/run_with_stderr.sh command args` to capture both stdout and stderr.

See https://github.com/anthropics/claude-code/issues/4711 for details.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/5264
2. https://github.com/anthropics/claude-code/issues/5305
3. https://github.com/anthropics/claude-code/issues/2231

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

I imagine that despite saying "Bash" its not actually executing in shell mode and is instead splitting the command into an arg vector.

Even when we explicitly mark this command as prohibited in CLAUDE.md and provide workaround instructions, Claude Code inevitably executes the command by habit, resulting in reactive troubleshooting after encountering errors. Using hooks appears to be the most effective solution. Claude Code implemented hooks for Claude Code.

#!/usr/bin/env python3
"""
Claude Code Hook: Bash Stderr Redirect Bug Preventer
================================================================
This hook runs as a PreToolUse hook for the Bash tool.
It prevents the known Claude Code bug where ANY shell operators get incorrectly
quoted when parsed by shell-quote and reconstructed, causing command failures.

The bug affects ALL redirections and operators when used with pipes, not just stderr.

Read more about hooks here: https://docs.anthropic.com/en/docs/claude-code/hooks

Installation (add to ~/.claude/settings.json):
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /home/ubuntu/workbench/projects/anthropic_hunt/scripts/hooks/bash_stderr_validator.py"
          }
        ]
      }
    ]
  }
}
"""

import json
import re
import sys

# COMPREHENSIVE patterns based on thorough testing
# These patterns catch ALL cases where shell-quote breaks operators
_COMPILED_PATTERNS = [
    # === FILE DESCRIPTOR REDIRECTIONS ===
    # N>&M - File descriptor to another FD (2>&1, 1>&2, 3>&1, etc.)
    (re.compile(r'\s+\d+>&[\d-]+\s*\|'), 'file descriptor redirect directly piped'),
    
    # N> file - FD to file (2>/dev/null, 3>output, etc.)
    (re.compile(r'\s+\d+>\s*[^\s|]+\s*\|'), 'file descriptor to file directly piped'),
    
    # N>> file - FD append to file (2>>error.log, 3>>output, etc.)
    (re.compile(r'\s+\d+>>\s*[^\s|]+\s*\|'), 'file descriptor append directly piped'),
    
    # N< file - FD from file (3<input, 4<data, etc.)
    (re.compile(r'\s+\d+<\s*[^\s|]+\s*\|'), 'file descriptor input directly piped'),
    
    # N<> file - FD read/write (5<>file, etc.)
    (re.compile(r'\s+\d+<>\s*[^\s|]+\s*\|'), 'file descriptor read/write directly piped'),
    
    # === BASH COMBINED REDIRECTIONS ===
    # &> file - Both stdout and stderr to file
    (re.compile(r'\s+&>\s*[^\s|]+\s*\|'), 'combined redirect to file directly piped'),
    
    # &>> file - Both stdout and stderr append
    (re.compile(r'\s+&>>\s*[^\s|]+\s*\|'), 'combined append directly piped'),
    
    # >& file - Alternative combined syntax
    (re.compile(r'\s+>&\s*[^\s|]+\s*\|'), 'alternative combined redirect directly piped'),
    
    # >&N - Implicit FD 1 to another FD (>&2 means 1>&2)
    (re.compile(r'(?<!\d)>&\d+\s*\|'), 'implicit stdout redirect directly piped'),
    
    # === BASH PIPE SHORTHANDS ===
    # |& - Pipe both stdout and stderr (equivalent to 2>&1 |)
    (re.compile(r'\s+\|&'), 'bash |& shorthand (pipes both stdout and stderr)'),
    
    # &| - Alternative syntax for |&
    (re.compile(r'\s+&\|'), 'bash &| shorthand (alternative for |&)'),
    
    # === SIMPLE REDIRECTIONS (CRITICAL GAPS FIXED 2025-08-11) ===
    # Simple stdout redirect to file before pipe (echo test > file | cat)
    # Match > not preceded by digit or & (to avoid matching 2> or &>)
    (re.compile(r'(?<!\d)(?<!&)>\s*[^\s|]+\s*\|'), 'stdout redirect to file before pipe'),
    
    # Simple stdin redirect from file before pipe (echo test < file | cat)  
    # Match < not preceded by digit (to avoid matching 3<)
    (re.compile(r'(?<!\d)<\s*[^\s|]+\s*\|'), 'stdin redirect from file before pipe'),
    
    # Simple append redirect before pipe (echo test >> file | cat)
    # Match >> not preceded by digit (to avoid matching 2>>)
    (re.compile(r'(?<!\d)>>\s*[^\s|]+\s*\|'), 'append redirect to file before pipe'),
    
    # === NO-SPACE REDIRECTIONS (Added 2025-08-11) ===
    # Handle cases like cmd>file|other where there are no spaces
    (re.compile(r'[a-zA-Z0-9_]>[^|]*\|'), 'redirect without spaces before pipe'),
    (re.compile(r'[a-zA-Z0-9_]<[^|]*\|'), 'input redirect without spaces before pipe'),
    (re.compile(r'[a-zA-Z0-9_]>>[^|]*\|'), 'append without spaces before pipe'),
    
    # Redirect at start of line (e.g., >output cat | grep)
    (re.compile(r'^\s*>[^|]+\|'), 'redirect at start before pipe'),
    (re.compile(r'^\s*<[^|]+\|'), 'input at start before pipe'),
    (re.compile(r'^\s*>>[^|]+\|'), 'append at start before pipe'),
    
    # === SPECIAL CASES ===
    # Broken syntax that would still trigger the bug (2 > &1)
    (re.compile(r'\s+\d+\s+>\s+&\d+\s*\|'), 'broken redirect syntax that triggers bug'),
    
    # Multiple redirects where at least one before pipe
    # This is complex - handled by checking for > or < before |
    (re.compile(r'[<>]+[^|]*\s+[<>]+[^|]*\|'), 'multiple redirects before pipe'),
]


def _is_safely_wrapped(command: str) -> bool:
    """Check if command is properly wrapped in bash -c with quotes."""
    command = command.strip()
    if not command.startswith('bash -c '):
        return False
    
    # Check for proper quoting
    rest = command[8:].strip()
    if (rest.startswith("'") and rest.endswith("'")) or \
       (rest.startswith('"') and rest.endswith('"')):
        return True
    return False


def _validate_stderr_redirect(command: str) -> tuple[bool, str]:
    """
    Check if command contains problematic shell operator patterns.
    
    The Claude Code bug affects ANY shell operators that get parsed
    by shell-quote when a pipe is present, as they get incorrectly
    quoted during reconstruction.
    
    Args:
        command: The bash command to validate
    
    Returns:
        (is_valid, error_message) tuple where is_valid is False if the command
        should be blocked, and error_message contains the reason and suggestion.
    """
    # Allow explicit bypass
    if '# claude-stderr-ok' in command:
        return True, ""
    
    # Check if already safely wrapped
    if _is_safely_wrapped(command):
        return True, ""
    
    # Must have a pipe for the bug to trigger
    if '|' not in command:
        return True, ""
    
    # Don't block if command starts with just a redirect (probably a typo)
    stripped = command.strip()
    if stripped and stripped[0].isdigit():
        # Starts with a number, might be just a redirect without command
        if re.match(r'^\d+[<>&]', stripped):
            return True, ""  # Let it fail naturally
    
    # Check all patterns
    for pattern, description in _COMPILED_PATTERNS:
        if pattern.search(command):
            # Escape single quotes in command for safe wrapping
            escaped_command = command.replace("'", "'\\''")
            safe_command = f"bash -c '{escaped_command}'"
            
            return False, (
                f"⚠️ Claude Code bug detected: {description}\n"
                f"Shell operators will be incorrectly quoted, causing failure.\n\n"
                f"Use one of these workarounds:\n"
                f"1. {safe_command}\n"
                f"2. Add '# claude-stderr-ok' comment to bypass this check\n"
                f"3. Split into separate commands without pipes"
            )
    
    # Additional check for complex patterns that regex might miss
    # Check for any redirect operators followed eventually by a pipe
    if re.search(r'[<>].*\|', command) or re.search(r'&[<>].*\|', command):
        # Do a more thorough check - does it look like a redirect?
        redirect_patterns = [
            r'\d+>&',     # FD redirect
            r'\d+>',      # FD output
            r'\d+<',      # FD input
            r'&>',        # Combined
            r'>&',        # Alternative combined
            r'>>',        # Append
            r'<<',        # Here doc
            r'<<<',       # Here string
        ]
        
        for rp in redirect_patterns:
            if re.search(rp + r'.*\|', command):
                escaped_command = command.replace("'", "'\\''")
                safe_command = f"bash -c '{escaped_command}'"
                
                return False, (
                    f"⚠️ Claude Code bug detected: potential redirect operator before pipe\n"
                    f"Shell operators may be incorrectly quoted.\n\n"
                    f"Use workaround:\n"
                    f"{safe_command}"
                )
    
    return True, ""


def main():
    try:
        input_data = json.load(sys.stdin)
    except json.JSONDecodeError as e:
        print(f"Error: Invalid JSON input: {e}", file=sys.stderr)
        # Exit code 1 shows stderr to the user but not to Claude
        sys.exit(1)
    
    tool_name = input_data.get("tool_name", "")
    if tool_name != "Bash":
        sys.exit(0)
    
    tool_input = input_data.get("tool_input", {})
    command = tool_input.get("command", "")
    
    if not command:
        sys.exit(0)
    
    # Validate the command for shell operator issues
    is_valid, error_message = _validate_stderr_redirect(command)
    
    if not is_valid:
        print(error_message, file=sys.stderr)
        # Exit code 2 blocks tool call and shows stderr to Claude
        sys.exit(2)


if __name__ == "__main__":
    main()

Going to chime in that I've been seeing this for a while on Windows native via git bash. I assumed it was a git bash bug or something but found this issue instead. It'll try to do 2 >& 1 | HEAD or similar on cargo outputs then Cargo goes o a test named 2, we don't have one I guess that's fine, and succeeds instead of failing! But with 0 run tests.

@bogini
Since you closed this Issue, I assumed the problem was resolved, so I ran claude update and tested with the latest version v1.0.73, but the issue didn't appear to have improved.

Claude Code said:

Regression: Shell operator parsing breaks common development patterns

Since v1.0.61, Claude Code incorrectly processes 2>&1 and glob patterns in piped commands, breaking workflows that worked in v1.0.60.

Impact

• Every command using 2>&1 | ... produces incorrect output (adds literal "2")
• Glob patterns in pipes fail entirely (*.md becomes literal "glob")
• Affects 100% of users combining stderr/stdout or using wildcards
• Workaround exists but requires wrapping every command in bash -c

Reproduction

# In Claude Code interactive mode:
echo "test" 2>&1 | head -1
# Expected: "test"
# Actual: "test 2"

ls *.md | wc -l
# Expected: count of .md files
# Actual: "ls: cannot access 'glob': No such file or directory"

Root Cause

v1.0.61 changed from regex splitting to shell-quote parsing but the reconstruction function only uses op field, discarding pattern data and mishandling adjacent operators.

// The bug (present in v1.0.61-v1.0.73):
D.push(G.op);  // Only pushes operator name, loses pattern/context

Fix Options

1. Revert to v1.0.60's regex approach (known working)
2. Properly reconstruct tokens: D.push(shellQuote.stringify([G]))
3. Handle stdin at process level instead of string manipulation

Test Case

echo "test" 2>&1 | head -1  # Must output "test" not "test 2"
ls *.md | head -3           # Must list files, not error on "glob"

Version History

• v1.0.55-v1.0.60: ✅ Working correctly
• v1.0.61: ❌ Regression introduced ("Fixed permissions checking for allowed-tools with Bash")
• v1.0.62-v1.0.73: ❌ Bug persists (12 versions, 17 days)

This is a regression that worked correctly for months before v1.0.61. The fix is straightforward - either revert the problematic change or correct the token reconstruction.

Oh no, a section was described as having a bug that went unfixed for 6 weeks - that's a hallucination! Checking npm shows it was actually 17 days. My apologies.

$ npm view @anthropic-ai/claude-code time --json | jq '{"v1.0.61": ."1.0.61", "v1.0.73": ."1.0.73", "v1.0.60": ."1.0.60"}'
{
  "v1.0.61": "2025-07-25T20:52:31.027Z",
  "v1.0.73": "2025-08-11T21:30:29.164Z",
  "v1.0.60": "2025-07-24T20:52:22.104Z"
}

@Rokurolize This is fixed in 1.0.74

Confirmed it seems fixed for me (1.0.77 here):

> Hi Claude - can you run `echo hello` and pipe it _and_ stderr to a file "output" please

● Bash(echo hello > output 2>&1)
  ⎿  (No content)

● Done. The command redirected both stdout and stderr to the file "output".

! cat output
  ⎿  hello

> Can you do the same but pipe stderr and stdout to `tee output`

● Bash(echo hello 2>&1 | tee output)
  ⎿  hello

● Done. The command echoed "hello" to both the terminal and the file "output" using tee.

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.