/stuck, diagnose frozen/slow Qwen Code sessions

The user thinks another Qwen Code session on this machine is frozen, stuck, or very slow. Investigate and present a diagnostic report.

What to look for

Scan for other Qwen Code processes (excluding the current one, exclude the PID you see running this prompt). Since Qwen Code is a Node.js CLI (#!/usr/bin/env node), the process name (comm column) is always node (or bun if run with Bun). Identify Qwen Code sessions by looking at the command column for a script path inside a directory whose name starts with qwen-code (matches qwen-code/, qwen-code-dev/, worktree clones, etc.), anchored to the start of the path or after / so unrelated names like analyze-qwen-code/ don't false-match, or a bin invocation ending in /qwen (the global symlink). Avoid loose qwen-code substring matching: it false-positives on plugin brokers that merely pass a qwen-code path as --cwd.

Signs of a stuck session:

• High CPU (>=90%) sustained, likely an infinite loop. Sample twice, 1-2s apart, to confirm it's not a transient spike.
• Process state D / U (uninterruptible sleep), often an I/O hang. Linux uses D, macOS/BSD uses U. The state column in ps output; first character matters (ignore modifiers like +, s, <).
• Process state T (stopped), user probably hit Ctrl+Z by accident.
• Process state Z (zombie), parent isn't reaping.
• Very high RSS (>=4GB), possible memory leak making the session sluggish.
• State S with low CPU, the most common hang signature: a hung HTTPS request to the model API. Not a process-level red flag on its own, but combined with the user reporting "stuck", treat it as a strong signal to run the network check in step 3.
• Stuck child process, a hung git, node, or shell subprocess can freeze the parent. Check pgrep -P <pid> (then ps -p for state, see step 3) for each session.

Argument validation