Uncaught exception: write EPIPE when exiting CLI

[vasil1729]

Summary

The CLI crashes with an uncaught write EPIPE exception during normal use — while using the command-code CLI to make changes to a codebase — and exits instead of finishing gracefully.

Expected Behavior

The CLI should handle EPIPE gracefully (e.g. exit cleanly without a stack trace) when the output pipe/socket is closed by the reader, and complete its work.

Actual Behavior

While using the CLI to make changes to a codebase, the process crashes with a CRITICAL uncaught exception:

✖ CRITICAL: Uncaught Exception!
  This is an unexpected error. Please file a bug report at
  https://github.com/CommandCodeAI/command-code/issues/new
  ✖ ERROR → Error
  ℹ REASON → write EPIPE
  ℹ ERROR STACK ↓
   Error: write EPIPE
      at afterWriteDispatched (node:internal/stream_base_commons:159:15)
      at writeGeneric (node:internal/stream_base_commons:150:3)
      at Socket._writeGeneric (node:net:966:11)
      at Socket._write (node:net:978:8)
      at writeOrBuffer (node:internal/streams/writable:570:12)
      at _write (node:internal/streams/writable:499:10)
      at Writable.end (node:internal/streams/writable:821:17)
      at Socket.end (node:net:737:31)
      at file:///home/ultimatum/.nvm/versions/node/v24.13.0/lib/node_modules/command-code/dist/cli.mjs:2:19182
      at new Promise (<anonymous>)

  ℹ Trace ID: 144418bdf5fae64c987ae6f3a84b9d8b

Steps to reproduce the issue

1. Run the cmd CLI in a codebase directory.
2. Ask it to make changes to the codebase (edit files, apply a change, etc.).
3. When the CLI finishes/exits, the uncaught write EPIPE crash occurs in Writable.end / Socket.end (dist/cli.mjs).

Command Code Version

1.28.4

Operating System

Linux (WSL2, kernel 6.18.33.2-microsoft-standard-WSL2)

Terminal/IDE

Terminal (default shell)

Shell

zsh

Additional context

• Node: v24.13.0 (via nvm)
• EPIPE occurs when the reader of the socket has gone away; suggest ignoring EPIPE on the final write/end and exiting cleanly.

[vasil1729]

Diagnosis

The crash is a race in the CLI's child-process runner, not a terminal/pipeline issue.

At the crash site (dist/cli.mjs, the new Promise in the spawn helper), the code does roughly:

const child = spawn(cmd, args, { stdio: ['pipe','pipe','pipe'], ... });
child.stdin?.end(input);   // no error handler attached

child.stdin is a net.Socket. The stack is Socket.end → Writable.end → write → EPIPE.

Sequence

1. cmd spawns a child process and feeds it the prompt via its stdin pipe.
2. The child exits early / closes its stdin (finishes its task and dies, or aborts) — the read end of the pipe closes.
3. The parent's buffered write is flushed after that → kernel returns EPIPE.
4. Node emits an 'error' event on child.stdin; with no error listener, it becomes an uncaught exception → the CRITICAL crash.

Why intermittent

Pure race: EPIPE fires only when the child's read end closes before the parent's pipe buffer flushes. Fast-exiting children (e.g. mid-edit subprocesses) lose that race more often.

Reproduced

// child closes stdin, parent then ends() with a large payload → EPIPE
const child = spawn('node', ['-e', 'process.stdin.destroy(); setTimeout(()=>{},300)'], { stdio: ['pipe','pipe','pipe'] });
child.stdin.on('error', (e) => console.log('EPIPE', e.code)); // handles it
child.stdout.once('data', () => child.stdin.end('x'.repeat(1_000_000)));
// => prints EPIPE instead of crashing

Suggested fix

Attach error handlers to the child's stdio streams before writing:

m.stdin?.on('error', (e) => { if (e.code === 'EPIPE') return; /* else report */ });

Same for stdout and stderr if they can EPIPE.

[vipulgupta2048]

Thanks for opening an issue @vasil1729 I fixed a similar issue but on macOS. Checking this one.