claude-code [BUG] Claude Code sandbox Bash tool loses pipe data when pipeline is last element

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?

Summary

When Claude Code's Bash tool runs commands in sandbox mode and a pipeline is the final element in the command list, data (stdout and stderr) is not passed through | or |& pipes to subsequent commands. It is completely lost; it does not reach the next command and does not appear in tool output.

Sink commands still execute and their own output is captured: seq 2 | wc outputs 0 0 0, showing wc ran but received nothing.

A simple workaround is to append a trailing semicolon: seq 2 | cat;

Environment

Claude Code 2.0.76
Claude Opus 4.5
Ubuntu 24.04.3 LTS
Linux 6.14.0-36-generic
Bash 5.2.21
Minimal Claude Code config (sandbox enable only):

{
  "sandbox": {
    "enabled": true
  }
}

Steps to Reproduce

Run Claude Code with the above config on an appropriate system and ask it to run commands in the sandbox. For example:

claude --print 'Use the Bash tool to run each of these commands in the sandbox (one at a time) and output the exact results from the tool:
```
seq 2 | cat
seq 2 | cat;
seq 2 | wc
seq 2 | wc;
```
Sample output format:
1. `first command`
output of first command (Bash tool message if none)
2. `second command`
...
'

Sample (nondeterministic) output:

## Results

1. `seq 2 | cat`
Tool ran without output or errors

2. `seq 2 | cat;`
```
1
2
```

3. `seq 2 | wc`
```
      0       0       0
```

4. `seq 2 | wc;`
```
      2       2       4
```

**Interesting finding:** There's a notable difference in behavior between commands with and without a trailing semicolon. The commands without semicolons appear to have issues with the pipe - `cat` produces no output and `wc` reports 0 lines/words/bytes. Adding a semicolon at the end causes the commands to work correctly. This suggests something unusual about how the sandbox handles pipes at the end of commands.

Behavior Pattern

Fails (pipeline is final element in list)

These commands do not have any output:

seq 2 | cat                         # basic
seq 2 | cat | cat                   # multi-stage
echo start; seq 2 | cat             # outputs "start"; pipeline loses data
echo start && seq 2 | cat           # outputs "start"; pipeline loses data
(seq 2) | cat                       # subshell as source
{ seq 2; } | cat                    # brace group as source
yes | head -1                       # SIGPIPE case
shopt -s lastpipe; seq 2 | cat      # lastpipe doesn't help

Works (pipeline wrapped or followed)

seq 2 | cat;                        # trailing semicolon
seq 2 | cat; true                   # any trailing command
(seq 2 | cat)                       # wrapped in subshell
{ seq 2 | cat; }                    # wrapped in braces
bash -c "seq 2 | cat"               # nested shell
echo "$(seq 2 | cat)"               # command substitution
seq 2 | cat & wait                  # background + wait (completion message shown)
seq 2 | cat # comment               # trailing comment
seq 2 | cat #                       # trailing comment character

Works (source uses redirection)

cat <<< "1" | cat                   # here-string
cat <<EOF | cat                     # here-doc
1
EOF
cat < <(seq 2) | cat                # process substitution with redirect
cat <(seq 2)                        # process substitution (not a pipeline)
seq 2 | cat > /tmp/x; cat /tmp/x    # output redirection works

stderr also affected

(echo "test" >&2) |& wc             # outputs "0 0 0" — wc received nothing
(echo "test" >&2) |& wc;            # outputs "1 1 5" — works with semicolon

⚠️ /dev/stdin may cause hangs

seq 2 | cat < /dev/stdin            # outputs 1,2 but may hang Claude Code afterward

(Separate bug being reported)

Technical Notes

Data does not flow in multi-stage pipelines without workaround:

rm -f /tmp/claude/test.txt
seq 2 | tee /tmp/claude/test.txt | cat    # no output; file is 0 bytes
seq 2 | tee /tmp/claude/test.txt | cat;   # outputs 1,2; file is 4 bytes

stdout in sandbox is a socket:

/proc/self/fd/1 -> socket:[12887910]

/dev/stdout and /dev/stderr are inaccessible:

seq 2 | cat > /dev/stdout           # No such device or address
seq 2 | tee /dev/stderr             # No such device or address

[Created in cooperation with Claude Code using Claude Opus 4.5]

What Should Happen?

see report above

Error Messages/Logs

Steps to Reproduce

see report above

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.0.76 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

No response

Jan 05 '26 02:01 archer-eric

Found 3 possible duplicate issues:

https://github.com/anthropics/claude-code/issues/8318
https://github.com/anthropics/claude-code/issues/11225
https://github.com/anthropics/claude-code/issues/15599

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

Jan 05 '26 02:01 github-actions[bot]

Note: This is an annoying problem, as Claude Code likes to run things like

commmand-with-long-output | head -20

This exits with no output and no error in the sandbox, and Claude Code assumes that command-with-long-output had no output, leading it down bad logic paths.

Jan 05 '26 20:01 archer-eric

I have verified that I am not the only one seeing this bug. A coworker sees the same problem on a Mac. Is nobody else using Claude Code sandboxes?

Jan 08 '26 01:01 archer-eric

workaround: I added this to the end of my ~/.claude/CLAUDE.md file:

## ALERT!

- There is currently a bug in Claude Code Shell tool when commmands are run in a sandbox: Pipes do not work correctly unless you append a ";" to the end of the entire command! Yes, it's strange, but we need to ensure that we always add ";" to the end of all commands when running in a sandbox until this bug is fixed.

With this, Claude Code (Opus 4.5) consistently adds " ;" to the end of every Bash tool command when running in the sandbox (even ones without pipes, which is fine).

Jan 08 '26 01:01 archer-eric

Still a problem in Claude Code v2.1.2:

 ▐▛███▜▌   Claude Code v2.1.2
▝▜█████▛▘  Opus 4.5 · Claude Max
  ▘▘ ▝▝    /home/[ELIDED]

❯ run in the sandbox with no trailing semicolon: echo hi | cat 

● Bash(echo hi | cat)
  ⎿  (No content)

● The command ran but produced no output. This demonstrates the pipe bug mentioned in your CLAUDE.md - without the trailing semicolon, the piped output doesn't appear.

❯ now try it with the trailing semicolon 

● Bash(echo hi | cat;)
  ⎿  hi

● With the trailing semicolon, it works correctly and outputs hi. The workaround is confirmed.

Jan 09 '26 23:01 archer-eric

Still a problem in Claude Code 2.1.17 on Ubuntu 24.04. This makes Claude Code with sandbox unreliable on Linux, as Claude Code is constantly piping commands to head and tail, and this bug prevents any output from showing up.

How does one get Anthropic's attention among the thousands of issues being reported?

$ claude --print 'Use the Bash tool to run each of these commands in the sandbox (one at a time) and output the exact results from the tool:     
```                                                                           
seq 2 | cat
seq 2 | cat;
seq 2 | wc
seq 2 | wc;
```
Sample output format:
1. `first command`
output of first command (Bash tool message if none)
2. `second command`
...
'

Here are the results:

seq 2 | cat (Tool ran without output or errors)

seq 2 | cat;
1
2
seq 2 | wc
      0       0       0
seq 2 | wc;
2       2       4
This confirms the sandbox pipe bug mentioned in CLAUDE.md. Without the trailing semicolon, pipes don't work correctly - either producing no output or incorrect results (0 lines/words/bytes). With the semicolon, the commands work as expected.

Jan 23 '26 03:01 archer-eric

I'm having a similar issue and have been forced to disable the sandbox because it interferes with operation. When developing, I prefer to access my development environment on my Ubuntu 22.04 LTS development machine via SSH from macOS, but the Linux sandbox may not be maintained.

Jan 26 '26 14:01 tsukumijima

Still a problem in Claude Code v2.1.29 on Linux using a sandbox.

The silent failure giving Claude Code misinformation has to be causing some really bad results for folks trying the sandbox on Linux, possibly causing them to lose respect for Claude Code, if not causing actual harm.

Feb 02 '26 06:02 archer-eric

"How does one get Anthropic's attention among the thousands of issues being reported?" The official way is through https://github.com/anthropics/claude-code/issues/21953
I don't want to derail the topic of this issue, but how is the sandbox usable for you in general on Ubuntu 24.04 https://github.com/anthropics/claude-code/issues/14719?
I don't reproduce your example in 10 tries on /etc/os-release:PRETTY_NAME="AlmaLinux 9.7 (Moss Jungle Cat)" with 2.1.17 (Claude Code), I also needed to add --dangerously-skip-permissions. I believe we may also need export DISABLE_PROMPT_CACHING=1

Your instructions:

Here are the results:

1. `seq 2 | cat`
Error: This Bash command contains multiple operations. The following part requires approval: seq 2

2. `seq 2 | cat;`
Error: This Bash command contains multiple operations. The following part requires approval: seq 2

3. `seq 2 | wc`
Error: This Bash command contains multiple operations. The following part requires approval: seq 2

4. `seq 2 | wc;`
Error: This Bash command contains multiple operations. The following part requires approval: seq 2

All four commands returned the same error about requiring approval for multiple operations.

rm -rf /tmp/test
cd /tmp/test
export DISABLE_PROMPT_CACHING=1

claude --dangerously-skip-permissions --print 'Use the Bash tool to run each of these commands in the sandbox (one at a time) and output the exact results from the tool:
```
seq 2 | cat
seq 2 | cat;
seq 2 | wc
seq 2 | wc;
```
Sample output format:
1. `first command`
output of first command (Bash tool message if none)
2. `second command`
...
'

Here are the results:

1. `seq 2 | cat`
```
1
2
```

2. `seq 2 | cat;`
```
1
2
```

3. `seq 2 | wc`
```
      2       2       4
```

4. `seq 2 | wc;`
```
      2       2       4
```

The trailing semicolon has no effect on the output in any of these cases.

bash --version
GNU bash, version 5.1.8(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
...

Feb 02 '26 06:02 marcindulak

@marcindulak

Thanks for the tip.
My current problems with sandbox on Ubuntu 24.04 are (especially the first):

https://github.com/anthropics/claude-code/issues/17087
- aka: https://github.com/anthropic-experimental/sandbox-runtime/issues/85
- which has been closed 15 minutes ago with https://github.com/anthropic-experimental/sandbox-runtime/pull/91
- looking forward the pain relief once it gets to stable
https://github.com/anthropics/claude-code/issues/16305
https://github.com/anthropics/claude-code/issues/16306

Thanks for trying. Neither export DISABLE_PROMPT_CACHING=1 nor --dangerously-skip-permissions improves my results with the current issue.

Feb 02 '26 09:02 archer-eric

When I mentioned the need for --dangerously-skip-permissions is because without it, your test case was blocked (returned Error: This Bash command contains multiple operations. The following part requires approval) , so some of our settings may differ.

Feb 02 '26 09:02 marcindulak

@marcindulak Ah yes, I probably allow the example commands like seq and cat and wc.

Feb 02 '26 09:02 archer-eric