[BUG] Freezes terminal most of the time when trying to access anything remotely related to tty devices

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?

#6237 Is still a problem. Was asked to reopen it if it was.

Please see the original ticket for.

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](https://github.com/belay-dotnet/Belay.NET); 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.

● Bash(stty -F /dev/ttyACM0 -a 2>/dev/null | head -5)
⎿  speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;

-> freeze...

● Bash(sudo screen -L -Logfile c6_serial.log /dev/ttyACM0 115200 &)...

-> freeze...

    ok that also freezes you. try just to access any tty device and see if you freeze

● Let me test with a simpler TTY device to confirm the issue:

● Bash(ls -la /dev/tty /dev/tty0 /dev/pts/0 2>/dev/null | head -3)
⎿  crw------- 1 kim tty 136, 0 Aug 20 12:24 /dev/pts/0
crw-rw-rw- 1 root tty 5, 0 Aug 21 11:18 /dev/tty
crw------- 1 root tty 4, 0 Aug 20 12:23 /dev/tty0

✶ Whisking… (esc to interrupt)

-> freeze...

What Should Happen?

Accessing TTY shouldn't freeze Claude

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.

Error Messages/Logs

Steps to Reproduce

Intermittent issue when accessing TTY devices. Ask claude to interact/read logs/etc and wait for it to happen.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.32 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Windows Terminal

Additional Information

_No response_