[BUG] Claude Code hangs entirely when /dev/stdin is read using Bash tool in a sandbox
Status Fixed / completed
Reported on v2.0.76
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 11 comments · opened Jan 5, 2026 · closed Feb 13, 2026
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?
_[Created with Claude Code using Claude Opus 4.5]_
Summary
When the Bash tool reads from /dev/stdin (or equivalents /dev/fd/0, /proc/self/fd/0) in sandbox mode, Claude Code hangs after the command completes. The command produces correct output, but Claude Code becomes unresponsive afterward (spinner stops, input blocked).
Hang occurs when:
/dev/stdinis read as a file argument (e.g.,cat /dev/stdin)/dev/stdinis used as a redirect with an external command as pipe source (e.g.,seq 2 | cat < /dev/stdin)
Does NOT hang when:
/dev/stdinis used as a redirect with a builtin as pipe source (e.g.,echo 1 | cat < /dev/stdin)- stdin is read normally without referencing
/dev/stdin(e.g.,catortimeout 1 cat)
By "hang", I mean:
- nothing on the display changes (not even the spinner)
- keys do not add text to the prompt
<Esc>does not have any effectCtrl-Cdoes not have any effect- The Terminal in which Claude Code was run must be closed
Environment
- Claude Code 2.0.76
- Ubuntu 24.04.3 LTS
- Linux 6.14.0-36-generic
- Bash 5.2.21
- Minimal Claude Code config with sandbox enabled:
{
"sandbox": {
"enabled": true
}
}Steps to Reproduce
Warning: This may hang Claude Code:
claude 'Run in sandbox: cat /dev/stdin'Behavior Pattern
Hangs
cat /dev/stdin # file argument, no input
cat /dev/stdin <<< "test" # file argument, with input
cat /dev/fd/0 # /dev/fd/0 equivalent
cat /proc/self/fd/0 # /proc/self/fd/0 equivalent
/bin/echo 1 | cat < /dev/stdin # redirect, external sourceDoes NOT hang
echo 1 | cat < /dev/stdin # redirect, builtin source
cat /dev/stdin <&- 2>/dev/null # stdin closed before readErrors (no hang)
cat < /dev/stdin <<< "test" # ENXIO: No such device or addressWhat Should Happen?
maybe don't hang
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_
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Note: This might sound like a problem that would never happen, but I've hit it multiple times since starting to use the Claude Code sandbox a week or so ago. It was always Claude Code that created the bash command to run, and it took me a while to figure out why it was hanging, as I needed to start a new Terminal and resume the Claude Code session each time.
same issue reading from an esp32 devboard:
timeout 5 cat /dev/ttyUSB0 2>&1 || truecrashes claude cli on ubuntu .Version: 2.1.2
Model: Default Opus 4.5 · Most capable for complex work
Similar Bash Tool Hang with no Output until timeout, But on Macos
Symptoms:
The Read tool works perfectly (instant output, items returned normally).
The Bash tool often hangs, stuck at running with no output.
For example, tmux -V (which should return immediately) hangs when executed via cc.
This happens consistently when cc triggers Bash from:
iTerm2
VS Code integrated terminal
It’s more likely to reproduce when multiple Bash commands run in parallel.
Important comparison:
Running the exact same commands manually in the system Terminal is fast and works normally.
The issue only occurs when commands are executed via cc’s Bash tool.
Recent changes:
Updated to the latest versions of:
Claude Code
tmux
iTerm2
oh-my-zsh
Everything worked fine before these upgrades.
Environment:
macOS
oh-my-zsh
~/.zshrc includes auto-initialization for:
conda
nvm
Suspicions:
Shell initialization changes after the oh-my-zsh upgrade
conda / nvm initialization blocking or slowing down non-interactive shells
Differences between cc-invoked shells (non-interactive / non-login) and normal Terminal sessions
Has anyone experienced cc Bash tool hanging with zsh + conda/nvm?
Any tips on how to debug or fix this would be greatly appreciated.
Similar Bash Tool Hang with no Output until timeout, But on Macos
Symptoms:
The Read tool works perfectly (instant output, items returned normally).
The Bash tool often hangs, stuck at running with no output.
For example, tmux -V (which should return immediately) hangs when executed via cc.
This happens consistently when cc triggers Bash from:
iTerm2
VS Code integrated terminal
It’s more likely to reproduce when multiple Bash commands run in parallel.
Important comparison:
Running the exact same commands manually in the system Terminal is fast and works normally.
The issue only occurs when commands are executed via cc’s Bash tool.
Recent changes:
Updated to the latest versions of:
Claude Code
tmux
iTerm2
oh-my-zsh
Everything worked fine before these upgrades.
Environment:
macOS
oh-my-zsh
~/.zshrc includes auto-initialization for:
conda
nvm
Suspicions:
Shell initialization changes after the oh-my-zsh upgrade
conda / nvm initialization blocking or slowing down non-interactive shells
Differences between cc-invoked shells (non-interactive / non-login) and normal Terminal sessions
Has anyone experienced cc Bash tool hanging with zsh + conda/nvm?
Any tips on how to debug or fix this would be greatly appreciated.
Similar Bash Tool Hang with no Output until timeout, But on Macos
Symptoms:
The Read tool works perfectly (instant output, items returned normally).
The Bash tool often hangs, stuck at running with no output.
For example, tmux -V (which should return immediately) hangs when executed via cc.
This happens consistently when cc triggers Bash from:
iTerm2
VS Code integrated terminal
It’s more likely to reproduce when multiple Bash commands run in parallel.
Important comparison:
Running the exact same commands manually in the system Terminal is fast and works normally.
The issue only occurs when commands are executed via cc’s Bash tool.
Recent changes:
Updated to the latest versions of:
Claude Code
tmux
iTerm2
oh-my-zsh
Everything worked fine before these upgrades.
Environment:
macOS
oh-my-zsh
~/.zshrc includes auto-initialization for:
conda
nvm
Suspicions:
Shell initialization changes after the oh-my-zsh upgrade
conda / nvm initialization blocking or slowing down non-interactive shells
Differences between cc-invoked shells (non-interactive / non-login) and normal Terminal sessions
Has anyone experienced cc Bash tool hanging with zsh + conda/nvm?
Any tips on how to debug or fix this would be greatly appreciated.
Clarification: The original bug described in this issue is a _complete_ hang of the entire Claude Code application, not just the Bash tool itself.
No keystrokes have any effect including
<Esc>,Ctrl-C,Ctrl-\The Terminal containing Claude Code must be closed to exit the program.
Problems that are not this specific bug should be opened as new issues.
With the latest Claude Code releases, I'm now seeing that it doesn't always cause the issue on the first run of the commands, but may require prompting it to run a command again to see the file and attempt the read.
If anybody/anyAI is going to actually spend time investigating this, drop a note and I'm happy to spend more time figuring out exactly what sequence reproduces it to save you time, but if this issue is going to sit ignored, I'll work on other stuff.
Workaround is to put in claude.md file to never use cat to stream from /dev instead use python as cat causes a crash. This seems to work for me :)
The original reported issue seems to be fixed as of Claude Code v2.1.42
Perhaps this in /release-notes 2.1.41 is somehow related (though it mentions FileReadTool instead of BashTool):
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.