claude-code icon indicating copy to clipboard operation
claude-code copied to clipboard
Published 1 month ago • verified publisher icon anthropics

[BUG] Claude Code hangs entirely when /dev/stdin is read using Bash tool in a sandbox

Open archer-eric opened this issue 2 months ago • 9 comments

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/stdin is read as a file argument (e.g., cat /dev/stdin)
  • /dev/stdin is used as a redirect with an external command as pipe source (e.g., seq 2 | cat < /dev/stdin)

Does NOT hang when:

  • /dev/stdin is 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., cat or timeout 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 effect
  • Ctrl-C does 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 source

Does NOT hang

echo 1 | cat < /dev/stdin           # redirect, builtin source
cat /dev/stdin <&- 2>/dev/null      # stdin closed before read

Errors (no hang)

cat < /dev/stdin <<< "test"         # ENXIO: No such device or address

What 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

archer-eric avatar Jan 05 '26 02:01 archer-eric

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/15003
  2. https://github.com/anthropics/claude-code/issues/14337
  3. https://github.com/anthropics/claude-code/issues/8049

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

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

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.

archer-eric avatar Jan 05 '26 20:01 archer-eric

same issue reading from an esp32 devboard: timeout 5 cat /dev/ttyUSB0 2>&1 || true crashes claude cli on ubuntu .

Version: 2.1.2

Model: Default Opus 4.5 · Most capable for complex work

rvdende avatar Jan 09 '26 14:01 rvdende

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.

aiyinyuedejustin avatar Jan 11 '26 11:01 aiyinyuedejustin

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.

aiyinyuedejustin avatar Jan 11 '26 11:01 aiyinyuedejustin

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.

aiyinyuedejustin avatar Jan 11 '26 11:01 aiyinyuedejustin

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.

archer-eric avatar Jan 11 '26 18:01 archer-eric

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.

archer-eric avatar Jan 11 '26 18:01 archer-eric

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 :)

rvdende avatar Jan 12 '26 03:01 rvdende