[BUG] Bash task causing lockup in subprocess / file handles as well as Claude Code itself.

Environment

• Platform (select one):
• [X] Anthropic API
• [ ] AWS Bedrock
• [ ] Google Vertex AI
• [ ] Other: <!-- specify -->
• Claude CLI version: 1.0.92
• Operating System: 24.04.2 LTS
• Terminal: tmux/ssh -> Windows Terminal

Bug Description

While using the Bash tool to run tests that interact with hardware, both the hardware and Claude Code lock up and nee to be forcefully killed.

I'm using Cluade Code to build a hardware interfacing library; which boils down to sending ascii data to an embedded device (which is running micropython) over USB CDC (serial / tty), the device processes that data then sends a response back up the usb cdc to the host.

There's hardware tests in this library which Claude Clode has been running as part of the development cycle, (implement, build, test, etc) which had been working great, however more and more recently the device was getting locked up and Claude Code was also getting locked up, usually during a Bash tool use that was relating to the tty device under test.

The exact same tests scripts run directly from ssh/bash run just fine for 100's of cycles, however when Claude Code run the same script it usually locks up within one or two iterations.

When I say locked up, I mean text input no longer works and even the little anthoropic logo ticker that flickers while active, freezes.
At this point ctrl-c / escape doesn't have any impact. It will stay this way for hours if I leave it. I generally have to kill the tmux session and/or switch to a different terminal to pkill the claude instance.

While in this locked up state, I can connect to the hardware device with a separate terminal all (normally mpremote) but it too would appear unresponsive to all normal commands. I was able to confirm via a hardware debugger though that the target processor itself appeared to be running normally, it was running through it's normal main / repl loop still.

I've now discovered that unplugging the usb device generally unfreezes claude code.

Similarly, without unplugging the device I've found that I can use lsof to find the open handle to the serial device then use gdb to forcefully close that handle from within the claude program - this unblocks the hardware and allows the terminal/mpremote to communicate with it normally again.
<details>
<summary>Click to expand details</summary>

``` bash
$ sudo lsof | grep ttyACM0
claude 826926 corona 24r CHR 166,0 0t0 3554 /dev/ttyACM0
claude 826926 826927 node corona 24r CHR 166,0 0t0 3554 /dev/ttyACM0
claude 826926 826928 node corona 24r CHR 166,0 0t0 3554 /dev/ttyACM0
claude 826926 826929 node corona 24r CHR 166,0 0t0 3554 /dev/ttyACM0
claude 826926 826934 node corona 24r CHR 166,0 0t0 3554 /dev/ttyACM0
claude 826926 826935 node corona 24r CHR 166,0 0t0 3554 /dev/ttyACM0
claude 826926 826936 node corona 24r CHR 166,0 0t0 3554 /dev/ttyACM0
mpremote 839011 corona 3uW CHR 166,0 0t0 3554 /dev/ttyACM0

$ sudo gdb -p 826926
...
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 826926

(gdb) call close(24)
$1 = 0
(gdb) detach
Detaching from program: /home/corona/.nvm/versions/node/v22.16.0/bin/node, process 826926
[Inferior 1 (process 826926) detached]
(gdb) exit

</details>


I've been investigating this for quite a few days now and believe I've narrowed it down to a subprocess pipe blocked kind of issue; it actually looks the same to me now as a well known issue with python subprocess handling as described in:
*  https://lucadrf.dev/blog/python-subprocess-buffers/ 
* https://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/

## Steps to Reproduce
I'm honestly not sure how to reproduce this without my harware / library project setup.
If it's "just" a subprocess stdio buffering issue then perhaps any subprocess with the right/wrong structure or timing of stdout would cause the same issue, but I'm not sure.

## Expected Behavior
Scripts / programs run though Claude Code Bash() tool behave the same way as if they're run from a "normal" ssh/bash session.

## Actual Behavior
Script / program is locking up both Claude Code and hardware.

## Additional Context
I'm happy to provide any further details or run tests if it would help.