[BUG] Agent ran `timeout 5 <electron-app> --version` as a sanity check, orphaned Electron child processes froze the desktop (hard reboot required)

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?

Summary

While asking Claude Code to install a downloaded Linux tarball (postman-agent-0.5.1-linux-x64.tar.gz, an Electron-based app from Postman), the agent ran a "sanity check" command that launched the GUI application directly inside the live desktop session. This spawned multiple Electron child processes (GPU process, zygote, renderer, crashpad handler) that were not fully terminated when the check's timeout expired, leading to resource contention that froze the desktop session. I had to force a hard reboot. The storage devices were never actually damaged — post-reboot kernel logs show both NVMe drives enumerating and mounting normally with zero I/O errors.

Environment

Ubuntu 26.04.1 LTS, GNOME/Wayland desktop, dual NVMe (nvme0n1, nvme1n1)

Timeline (local time, UTC+7)

• 12:43 — Finished downloading postman-agent-0.5.1-linux-x64.tar.gz to ~/Downloads.
• 12:46–12:50 — Claude Code session (~/Downloads project) installs the app:
• Extracted tarball to ~/.local/opt/Postman Agent/
• Created launcher at ~/.local/bin/postman-agent
• Created desktop entry at ~/.local/share/applications/postman-agent.desktop
• 12:46:56 — Agent ran, as a final verification step:

timeout 5 ~/.local/bin/postman-agent --version 2>&1 | tail -20
intending a "headless-safe" check that the binary responds to --version.

• 12:47:04 — Command returned Exit code 143 / Terminated. The app did not exit on its own within 5 seconds and was killed by timeout. (The binary is an Electron GUI app and does not implement --version; invoking it just launches the full application.)
• 12:47:21 — Agent reported the install complete, noting the binary "started but is waiting for a display, which is normal for a GUI app," without flagging any risk.
• Shortly after — Machine became unresponsive; the desktop (file manager / storage detection) appeared to lose track of disks. Forced hard reboot.
• 13:21:27 — Boot time confirms a fresh reboot at this point (verified via uptime -s).

Root Cause

1. The agent invoked a live-display GUI/Electron binary directly (not headless-safe as assumed) as a "test."
2. Electron apps are multi-process by design (main, GPU, zygote, renderer, crashpad handler). timeout only sends SIGTERM to the immediate child, not the whole process tree/group.
3. When timeout killed the parent after 5 seconds, one or more Electron child processes were orphaned and kept running, competing for GPU device access (/dev/dri/*) and system resources within the same active Wayland session used by the desktop shell.
4. This contention made GNOME Shell / Nautilus unresponsive, which presented as the disks being undetectable — not an actual storage hardware fault.

Evidence (collected post-incident)

• uptime -s → boot time 2026-09-19 13:21:27, confirming a reboot immediately before the next Claude Code session.
• journalctl -k -b (post-reboot) → nvme0 and nvme1 enumerated and mounted cleanly, no I/O errors, resets, or NVMe failures — ruling out disk hardware failure.
• Re-inspection of the prior session's transcript confirmed the exact command and its Terminated (143) result.
• In a follow-up session, launching the same app normally (via its installed launcher, without timeout ... --version) worked correctly with no orphaned processes, no zombies, and normal system load — the app itself is not unstable; the trigger was the agent's verification method.

Impact

• Full desktop freeze requiring a hard reboot.
• Risk of data loss/corruption from an unclean shutdown (none occurred here, but the risk exists generally).
• No permanent hardware/filesystem damage found.

Suggested fix

• Agents should not execute unknown/untrusted GUI binaries directly inside a live user desktop session to "test" them, especially without first confirming the binary supports a lightweight flag like --version (e.g. via --help exit code, or checking resources/app/package.json for CLI support). The agent should ask the user or use a safer check, such as verifying the binary is executable and correctly linked without running it.
• When a process must be time-boxed, use timeout --signal=KILL -k <grace> <seconds> <cmd> combined with killing the whole process group (e.g. setsid / kill -- -$PGID) rather than plain timeout, since GUI/Electron/Chromium apps reliably spawn children that survive SIGTERM to the parent.

What Should Happen?

The agent should not execute an unknown GUI binary inside the user's live
desktop session just to test it. Safer options: check the file is executable
and linked correctly (file, ldd) without running it, check whether a CLI flag
is supported first, or ask the user before launching. If a process must be
time-boxed, kill the whole process group (setsid + kill -- -PGID, or
timeout -k with SIGKILL) instead of relying on plain timeout.

Error Messages/Logs

$ timeout 5 ~/.local/bin/postman-agent --version 2>&1 | tail -20
Exit code 143 (Terminated)

Agent response afterwards:
"started but is waiting for a display, which is normal for a GUI app"

Post-reboot: journalctl -k -b shows nvme0 and nvme1 enumerated and mounted
cleanly, no I/O errors or resets. uptime -s: 2026-09-19 13:21:27

Steps to Reproduce

1. Download an Electron-based Linux app tarball (e.g. postman-agent-0.5.1-linux-x64.tar.gz)
2. Ask Claude Code: "install this app"
3. Agent installs it and runs timeout 5 <launcher> --version as a check
4. GUI launches, gets SIGTERM after 5s, child processes remain
5. Desktop session becomes unresponsive

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.236

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Environment: Ubuntu 26.04.1 LTS, GNOME/Wayland, dual NVMe.

Timeline (UTC+7):

• 12:46:56 agent ran the timeout ... --version check
• 12:47:04 command terminated (143)
• 12:47:21 agent reported install complete, no risk flagged
• shortly after: desktop froze, hard reboot
• 13:21:27 reboot confirmed via uptime -s

Launching the app normally afterwards worked fine with no orphaned
processes, so the trigger was the verification method, not the app.

Root cause: timeout only sends SIGTERM to the direct child, so Electron's
GPU/zygote/renderer/crashpad processes survived and contended for
/dev/dri/* in the live session.