Bug: panic on broken pipe (SIGPIPE) — crash dump when piping codewhale output

[BrathonBai]

Describe the bug

When codewhale output is piped to another command (e.g. codewhale doctor | head) and the receiving end exits before codewhale finishes writing, the process panics with a noisy crash dump instead of terminating cleanly.

Steps to reproduce

codewhale doctor | head -20

Expected behavior

Process should exit cleanly (exit code 141, SIGPIPE) — standard Unix behavior for piped commands.

Actual behavior

Process panicked
Location: std::io::stdio.rs:1165:9
Panic: failed printing to stdout: Broken pipe (os error 32)

Crash dumps appear in ~/.deepseek/crashes/.

Environment

• OS: Kali Linux 2026.3 (also reproducible on any Linux/macOS)
• Version: v0.8.66

Root cause

Many execution environments (systemd, Docker, some shells) inherit SIGPIPE set to SIG_IGN. When SIGPIPE is ignored, write(2) returns EPIPE instead of delivering the signal. Rust println!() treats any std::io::Error from write_all as fatal and panics.

Proposed fix

Reset SIGPIPE to SIG_DFL in main.rs before any output:

#[cfg(unix)]
unsafe {
    libc::signal(libc::SIGPIPE, libc::SIG_DFL);
}

Patch available (can submit as PR if interested).

Evidence

Two panic records found in ~/.deepseek/crashes/:

Time (CST)	Error
2026-07-04 11:50:39	failed printing to stdout: Broken pipe (os error 32)
2026-07-04 11:58:29	failed printing to stdout: Broken pipe (os error 32)

[github-actions]

Thanks @BrathonBai for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.