File descriptor leak causes Claude process to hang on blocked SCSI device I/O

Description

When running bash commands that interact with SCSI devices, Claude Code's process itself can end up holding file descriptors to those devices. If a device doesn't respond (e.g., a DVD-ROM without media), Claude's main process blocks in kernel sg_read state and becomes completely unresponsive.

Expected Behavior

Child processes (bash, sg_inq, etc.) should hold device file descriptors, not the parent Claude process. Killing or timing out child processes should recover the session.

Actual Behavior

Claude's process directly holds the SCSI device fd and blocks in sg_read kernel state. No child bash process is visible. The only recovery options are:

1. gdb -p <pid> -batch -ex 'call (int)close(<fd>)' to forcibly close the fd
2. Killing the Claude process entirely

Steps to Reproduce

1. Start Claude Code (VSCode extension or CLI)
2. Run a command that iterates over SCSI devices:

``bash
for sg in /dev/sg*; do
sg_inq -r "$sg" 2>/dev/null | head -5 || true
done
``

1. If one of the devices is unresponsive (e.g., optical drive without media), Claude hangs

Diagnostic Evidence

Process state showing Claude itself blocked on SCSI read:

$ cat /proc/<claude_pid>/wchan
sg_read

$ ls -la /proc/<claude_pid>/fd | grep /dev/sg
lr-x------. 1 user user 64 Jan 27 21:44 35 -> /dev/sg1

Process tree showing no bash child - only clangd MCP server:

claude(<pid>)-+-clangd.main(<pid>)
              |-{claude}(...)

Environment

• Claude Code VSCode Extension version: 2.1.20
• OS: RHEL/Rocky Linux 9 (kernel 5.14.0-570.44.1.el9_6.x86_64)
• The issue occurred with --mcp-config containing claude-vscode server

Workaround

Use timeout wrapper for all SCSI commands:

timeout 5 sg_inq /dev/sgX

Root Cause Hypothesis

File descriptor leakage during process spawning - possibly missing close-on-exec flags or improper fd handling when setting up pipes for bash commands.