[BUG] Terminal crashes with EPERM error when killing long-running sudo processes with timeout

Resolved 💬 3 comments Opened Sep 19, 2025 by tirans Closed Sep 25, 2025

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?

Claude Code terminal crashes completely with SystemError: kill() failed: EPERM: Operation not permitted when:

Running long-running bash commands with timeout (especially with sudo)
Commands timeout after specified duration (e.g., 3 minutes)
Attempting to interrupt commands with ESC
The terminal dumps minified JavaScript/TypeScript code and becomes unresponsive, requiring a full restart of Claude Code interface.

What Should Happen?

Commands should timeout gracefully without crashing the terminal
Process termination should handle permission errors appropriately
ESC should successfully interrupt long-running commands
Error messages should be user-friendly, not JavaScript stack traces
Terminal should remain functional after command timeout

Error Messages/Logs

SystemError: kill() failed: EPERM: Operation not permitted
 syscall: "kill",
   errno: 1,
    code: "EPERM"

      at fBZ (/$bunfs/root/claude:122:3104)
      at <anonymous> (/$bunfs/root/claude:122:2976)
      at forEach (1:11)
      at <anonymous> (/$bunfs/root/claude:122:2951)
      at forEach (1:11)
      at yBZ (/$bunfs/root/claude:122:2923)
      at <anonymous> (/$bunfs/root/claude:122:2850)
      at Q (/$bunfs/root/claude:122:3333)
      at emit (node:events:98:22)

Bun v1.2.19 (Linux x64 baseline)

Steps to Reproduce

Create a verification script that runs for several minutes:
cat << 'EOF' > /tmp/test-timeout.sh
#!/bin/bash
echo "Starting long-running process..."
for i in {1..180}; do
echo "Running... ($i/180)"
sleep 1
done
EOF
chmod +x /tmp/test-timeout.sh

Run the script with sudo and a timeout through Claude Code:
sudo /tmp/test-timeout.sh # with 3m timeout in Claude Code
Wait for the timeout to occur (3 minutes) OR try to interrupt with ESC

Terminal will crash with EPERM error and dump minified JavaScript code

Alternative reproduction with infrastructure commands:

Any MAAS deployment verification

sudo python3 deploy-maas.py --verify # with timeout

OR

sudo ./scripts/verify-maas.sh # with timeout

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.0.119

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

Context

  • Issue occurs during infrastructure automation tasks
  • Specifically when running MAAS deployment and verification scripts
  • Commands that spawn multiple child processes are most affected
  • Sudo commands are particularly problematic

Impact

  • Severity: High - Complete terminal crash
  • Frequency: Consistent - Happens every time with long-running sudo commands
  • Workflow Impact: Significant - Prevents effective infrastructure automation

Technical Details

  • Working directory: /home/dir/PycharmProjects/infra/scripts
  • Project type: Infrastructure as Code (Terraform, Ansible, Python orchestration)
  • Common failing commands:
  • sudo python3 deploy-maas.py
  • sudo ./scripts/setup-maas-snap.sh
  • sudo /tmp/verify-maas.sh

Potential Root Cause

The Bun runtime appears to lack proper permissions to kill child processes spawned with sudo. The process management system doesn't handle EPERM errors gracefully, causing the entire terminal to crash instead of displaying a user-friendly error message.

Suggested Fix

Implement proper error handling for EPERM errors in the process termination code, with fallback methods for killing processes (e.g., using pkill, sending SIGTERM before SIGKILL, or handling permission denied gracefully).

Workarounds Attempted

  • Running commands without timeout (not always feasible)
  • Using background processes (loses real-time output)
  • Shorter timeout durations (doesn't prevent crash)

None of these workarounds solve the underlying issue.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗