CRITICAL: uncaught exception `write EOF` terminates the session (WriteWrap.onWriteComplete)

[PedroMartpico]

Summary

Hello, and thank you for your work on Command Code.

During an ordinary working session the CLI terminated unexpectedly with a critical uncaught exception. The reported reason is write EOF, raised from Node’s internal stream write-completion handler (WriteWrap.onWriteComplete). The crash banner itself invites users to open a report, so I am documenting it here as accurately as I can.

Impact: the process exits abruptly, the session cannot be resumed, and any in-progress context and work is lost, which forces a restart mid-task.

Trace ID: d094858d83de400ea8ee63f7e5f8159d

Expected Behavior

Command Code should tolerate a stream being closed underneath it. A failed write on a broken pipe or socket should be handled gracefully — retried or safely discarded — so that only the affected operation fails while the session stays alive.

If the session genuinely cannot continue, the CLI should exit cleanly with a concise, actionable message (what broke, what the user can do next), rather than surfacing an uncaught exception and a raw Node stack trace.

Actual Behavior

The process raised an uncaught exception and terminated immediately. Verbatim terminal output:

✖ 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 EOF
ℹ ERROR STACK ↓
 Error: write EOF
    at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:87:19)
ℹ Trace ID: d094858d83de400ea8ee63f7e5f8159d
  Share this ID with support to help debug your issue.

The failure originates asynchronously in WriteWrap.onWriteComplete, so it does not appear to be captured by the surrounding error handling and reaches the top-level uncaught-exception handler.

Steps to reproduce the issue

I have not yet been able to reproduce the crash deterministically — it appeared during normal use. The sequence was:

1. Start Command Code 1.32.1 from the Windows system command line (no external IDE).
2. Work normally in the session: sending prompts and letting tool calls run, including shell tools that spawn cmd.exe and pwsh child processes.
3. At a non-deterministic point, the CLI prints the critical uncaught exception shown above and exits.
4. The session cannot be resumed; Command Code has to be restarted.

I would be glad to add the exact sequence, timings and a redacted session export if I manage to trigger it again — please let me know which details would be most useful to you.

Command Code Version

1.32.1

Operating System

Windows

Terminal/IDE

Command Code CLI on Windows — no external IDE; run directly from the system command line.

Shell

cmd.exe for system commands; pwsh (PowerShell 7+) for the PowerShell tool (powershell.exe 5.1.26100 also present).

Session file (optional)

No response

Fix prompt (optional)

Context: an uncaught write EOF escapes from Node’s asynchronous write-completion path (WriteWrap.onWriteComplete) and crashes the CLI on Windows. This is the Windows named-pipe counterpart of the EPIPE race already diagnosed in #716.

Where it lives: every place Command Code writes to a pipe or socket — the child-process runner (child.stdin.end(...) / write(...)), MCP stdio transports, the HTTP/streaming client, and the terminal writer.

What is correct: attach an error listener to every stdio stream before the first write, and swallow (or log at debug level) EPIPE, ECONNRESET and EOF. In addition, the top-level process.on('uncaughtException') handler should classify these transport errors as recoverable: abort only the affected operation, log a concise warning, and keep the session alive instead of terminating the process.

How to check: spawn a child that closes its stdin immediately and then write a large payload to it; assert the CLI reports the failed write and continues rather than exiting with a critical uncaught exception. Repeat on Windows (named pipes, which surface EOF) and on POSIX (EPIPE).

Additional context

Environment

• Command Code: 1.32.1 (command-code --version)
• OS: Windows (win32)
• Node: v24.19.0
• pnpm: bundled (10.34.5 in the project)
• Terminal: Command Code CLI run from the system command line, no external IDE
• Shells: cmd.exe for system commands, pwsh (PowerShell 7+) for the PowerShell tool (powershell.exe 5.1.26100 also present)

Diagnostics

• Trace ID: d094858d83de400ea8ee63f7e5f8159d
• Stack: Error: write EOF at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:87:19)
• write EOF is raised when a write completes against a handle whose peer has already gone away — on Windows named pipes it is the counterpart of EPIPE on POSIX. This points to a pending write on a transport (child-process stdio, MCP server pipe, or a network stream) that is torn down while the write is still in flight.
• Given the shell setup above, the CLI routinely spawns both cmd.exe and pwsh child processes, so a short-lived child closing its stdin before the parent flushes is a plausible trigger.

Possibly related

• Uncaught exception: write EPIPE when exiting CLI #716 — write EPIPE when exiting the CLI, diagnosed there as a race on child.stdin.end() with no error listener attached.
• CRITICAL: Uncaught Exception - write EPIPE #715 — CRITICAL: Uncaught Exception, write EPIPE.

The error code and stack frame differ here (write EOF from WriteWrap.onWriteComplete, i.e. the asynchronous write-completion path rather than Socket.end), so I am filing it separately; please feel free to close this as a duplicate if you consider it the same root cause.

I have not attached a session export, as it may contain project-sensitive information — I am happy to provide a redacted one on request.

Thank you for looking into this. I remain available for any further diagnostic detail you may need.

[ahmadawais]

@naymurdev check