CommandCodeAI / CommandCodeAI/command-code
CRITICAL: Uncaught `write EPIPE` on macOS kills the session after a large built-in read_file result (no MCP involved)
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 4k
- Forks
- 350
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
Summary
On macOS, Command Code dies with an uncaught Error: write EPIPE (WriteWrap.onWriteComplete, node:internal/stream_base_commons:87:19) immediately after a built-in read_file tool result is large. No MCP server is involved, and this is not Windows.
The existing EPIPE/EOF issues are all pinned to either Windows or MCP responses (#716, #725, #859, #793). This is the first report of the same crash class on macOS, triggered by a built-in tool (multi-file read_file) rather than MCP. The result is fatally unrecoverable: the TUI closes and the session is gone.
Expected Behavior
A tool result that is too large to write back to the terminal should be truncated/spilled to disk and surfaced as a handled, recoverable condition (or a controlled error) — the same way tool output is normally capped. A failed write on the output stream should never become an uncaught exception that kills the process. The transcript already contains the tool result, so the session should survive.
Actual Behavior
A single read_file call that requested several large files returned ~97.7 KB (the tool's own output cap — it reported Read 3/3 files, capped at 97.7 KB, and skipped the 4th file), and immediately after, while the loop rendered/wrote the result, the CLI printed:
✖ 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 WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:87:19)
ℹ Trace ID: 9221bc3418843be38a38a601e32fdce3
READ[3] [Skill(command-code-knowledge/reference/byok.md), Skill(command-code-knowledge/reference/mcp.md) (+2 more)]
The trailing READ[3] … (+2 more) line shows the failing tool call: a read_file whose result carried the four command-code-knowledge/reference/*.md skill files. The process exited; the session was unrecoverable.
Notes on the trigger:
- No MCP server was configured or called in this session (
~/.commandcode/mcp.jsonand.mcp.jsondo not exist). - The read was a plain built-in
read_file, not an MCP tool result. - The result was large enough to hit the tool's truncation cap (97.7 KB) and it had already been persisted before the crash — the payload was successfully produced; only the write-back to the stream failed.
Trace ID: 9221bc3418843be38a38a601e32fdce3
Steps to reproduce the issue
- macOS, Command Code v1.56.0, Node v24.21.0, Apple Terminal, zsh.
- In a single tool call, ask
read_filefor several large files whose combined result is at or above the tool's ~97.7 KB output cap (in my case:byok.md,mcp.md,hooks.md,skills.mdfrom the bundledcommand-code-knowledgeskill reference — each tens of KB). - The tool returns
Read 3/3 files, notescapped at 97.7 KB, and skips one file. - Immediately after the result is produced, the CLI throws uncaught
write EPIPEand exits.
The crash appears to be timing-dependent on how fast the large payload is written to the output stream — hence not 100% reproducible per call, but reliably reachable by making a single tool result large.
Command Code Version
1.56.0
Operating System
macOS
Terminal/IDE
Apple_Terminal (488)
Shell
zsh
Session file (optional)
Not attached (the session died at the crash; the transcript is available locally if useful). Trace ID 9221bc3418843be38a38a601e32fdce3 should locate it server-side.
Fix prompt (optional)
Command Code v1.56.0 on macOS throws an uncaught
Error: write EPIPEatWriteWrap.onWriteComplete (node:internal/stream_base_commons:87:19)right after a large built-inread_fileresult (~97.7 KB, multi-file) is produced, and the process exits. No MCP is involved.Where: the output/stream write path that renders tool results back to the TUI — the same path implicated by the
write EOFreports in #725/#793/#859, but here reached via a built-in tool on macOS rather than an MCP response on Windows.What's correct: EPIPE/EOF on the output stream must not be an uncaught exception. Route the tool-result write through a handler that (a) tolerates a closed/backpressured pipe, (b) truncates or spills oversized results to disk (the existing
tooloutspill directory pattern) before writing, and (c) on write failure surfaces a recoverable error and keeps the session alive — the result is already persisted, so nothing should be lost.How to check: reproduce by issuing a single
read_filefor several large files (combined result ≥ the ~97.7 KB cap) and confirm the CLI truncates/spills the result and continues, rather than exiting with EPIPE. Regression-test with output streamed into a pipe whose reader closes early (cmd … | head -c 1000) to exercise the same broken-pipe path.
Additional context
- This is the macOS (non-MCP) instance of the crash family tracked by #716, #725, #793, #859; those are all Windows and/or MCP-response-triggered. Filing separately because the trigger (built-in
read_file, darwin) is distinct, which may point at the shared write path rather than MCP-specific handling. - Related: #783 (OOM resuming long session) and #767 (uncaught exception on a large
write_file) both show large payloads reaching the same fragile write path. - Environment: Command Code installed as a global npm package under mise;
node --versionv24.21.0;sw_versreports macOS 27.0 (build 26A428), arm64. - The
command-code-knowledgeskill instructs the agent to read multiple large reference files, so this trigger is reproducible by design for anyone using that skill.
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Empieza por la ruta de escritura de output/stream que renderiza los resultados de las herramientas en la TUI, usando como contexto los issues relacionados con EPIPE/EOF. Reproduce el problema con un resultado grande de read_file integrado y con la salida canalizada a un lector que se cierra antes de tiempo, como cmd … | head -c 1000. Se considera completado cuando el resultado se trunca o se vuelca, el fallo se gestiona y la sesión no termina con un EPIPE no capturado.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- macos, node.js
- Área
- cli, operating-systems
- Tipo de issue
- Error
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Activo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 48/100