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

[APIUM]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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

[APIUM]

For anyone that finds this, the solution in the other thread is still working for me. We shouldn't have to patch Claude to be able to use it, but at least we have a workaround.

---

I liked the deployment of @andrewleech 's fix, but it doesn't work with the new native Claude Code as it uses NODE_OPTIONS preload modules. Have updated it to use LD_PRELOAD, it hasn't crashed for me yet but I've one just started using it today.

Same deployment, I put it in ~/.local/bin, give it chmod +x and then just run claude-safe instead of claude. You'll want gcc installed. Only tested on Linux, should work on MacOS I'd think.

claude-tty-safe-v0.2.0.zip

Edit: Updated to fix error with LD_PRELOAD being inherited into child processes such as gcc and causing trouble

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Freezes terminal most of the time when trying to access anything remotely related to tty devices. #6237
2. [BUG] Claude Code crashes/hangs when Read tool attempts to access /dev/ttyACM* or /dev/ttyUSB* serial devices #17068
3. [BUG] Claude Code automatically opens and gets stuck reading from /dev/ttyACM* devices causing complete lockup #7607

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

[APIUM]

Found 3 possible duplicate issues:

1. [[BUG]  Freezes terminal most of the time when trying to access anything remotely related to tty devices. #6237](https://github.com/anthropics/claude-code/issues/6237)

2. [[BUG] Claude Code crashes/hangs when Read tool attempts to access /dev/ttyACM* or /dev/ttyUSB* serial devices #17068](https://github.com/anthropics/claude-code/issues/17068)

3. [[BUG] Claude Code automatically opens and gets stuck reading from   /dev/ttyACM* devices causing complete lockup #7607](https://github.com/anthropics/claude-code/issues/7607)

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

We were asked specifically to reopen it from #6237

[APIUM]

I am going to close this, I have been retesting with the latest version (not patched with the above fix) and I haven't had the issue again.

[github-actions]

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.