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

[kimasplund]

● 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...

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Bash commands ignore BASH_DEFAULT_TIMEOUT_MS and hang indefinitely #3964
2. [BUG] Claude Code CLI hangs forever on Bash()/shell commands in WSL (even with correct user/permissions, native Linux path) #5010
3. Terminal Uncontrolled Pagination Animation Causing UI Freeze #1742

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

[andrewleech]

I just raised a new issue that does look like a variant of this one, so I'll close mine and add the details here

---

Environment

• Platform (select one):
  • Anthropic API
  • AWS Bedrock
  • Google Vertex AI
  • Other:
• 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.

Click to expand details

$ 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

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.

[dotdioscorea]

I have also been running into what sounds like the exact same issue. I am trying to get claude code to write a serial driver for a nordic development board, and python pytests to test its functionality.

Regardless of whether I am using the board's Jlink serial port or a separate FTDI cable, claude code will invariably freeze up within one or two interactions of the serial port device. Interestingly it seems to happen even if claude is not directly interacting with the port, eg running a python script to read from it. As with andrewleech, replugging the port frees up claude, but it will normally freeze up again shortly after.

While frozen, the working animation ascii thing stops, I cannot type, cannot ctrl c - nothing works. The moment I unplug the offending usb port, it continues where it left off. I am running on a laptop with debian installed, the issue happens if I run in the local terminal or ssh'ing into the laptop.

Its a shame, it renders claude code unusable for this sort of embedded work at the moment.

[cptkoolbeenz]

+1 Hangs when trying to access the serial port through bash or Python.
One pseudo-workaround is to run CC in WSL, then have it write Python to be run from PowerShell.

[andrewleech]

I'm thinking I should try an older version but haven't quite figured out just how old I'll need to go

[dstude]

workaround I found handy: using firejail --private-dev claude and asking claude to run stuff through ssh

shamefully, i opened this dupe but hopefully eases the pain

[andrewleech]

workaround I found handy: using firejail --private-dev claude and asking claude to run stuff through ssh

Ah yes, that's an (annoying) great idea. Similarly can probably use a docker container and/or separate computer and still tell claude to execute everything via ssh!