MaxListenersExceededWarning for resize after resume; one run later loses shell spawning with persistent EBADF

[LittleTOXA]

Summary

Summary

Long-running/resumed Command Code sessions intermittently stop before the requested task is complete. With warning traces enabled, two independent resumed sessions produced the same warning from the same bundled source location:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected.
11 resize listeners added to [Socket]. MaxListeners is 10.
...
at file:///opt/homebrew/lib/node_modules/command-code/dist/cli.mjs:3:1248967
at commitHookEffectListMount (.../react-reconciler.production.js:6718:26)
at commitPassiveMountOnFiber (.../react-reconciler.production.js:8144:25)

In one of the runs, subsequent shell tools eventually started failing persistently with spawn EBADF, including commands as simple as true and echo. File-reading tools continued to work. Restarting/resuming can make the problem disappear temporarily, so the behavior appears intermittent.

I am not claiming that the resize-listener leak necessarily causes EBADF, but they occurred in the same process and the listener warning is independently reproducible.

Environment

• Command Code: 1.53.0
• Node.js: v25.6.1
• OS: macOS 26.6.2 (25G83), arm64
• Terminal: Apple Terminal, TERM=xterm-256color
• Command Code dependency: ink@7.1.0
• Models/providers tested:
  • baseten/zai-org/GLM-5.3-Flash
  • cheaperinference/glm-5.3-flash

The installed package declares Node.js >=22, so the active Node version satisfies its declared engine constraint.

Evidence

Two minimized sanitized traces are attached:

• commandcode-178c-sanitized.log: listener warning in a Baseten session, followed by successful continuation after manual input.
• commandcode-c89132d7-sanitized.log: identical listener warning in a CheaperInference session, followed later by persistent spawn EBADF for trivial local commands.

The full session transcripts are available privately if needed. They are not attached publicly because tool results contain project and infrastructure details.

Possibly related reports

• Model suddenly stop working #601 — long sessions periodically stop with pending work and no error.
• (node:20563) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 resize listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit (Use node --trace-warnings ... to show where the warning QwenLM/qwen-code#7159 — the exact 11 resize listeners added to [WriteStream] warning; the linked fix reportedly shares a single terminal-size listener instead of attaching one per component instance.
• CLI hangs after completed generation run; usage shows completed but no assistant response #466 — completed generation with no assistant response displayed/saved (not identical, but potentially related to response/stream handling).

Expected Behavior

Expected behavior

• Mounting/unmounting or resuming the TUI should not accumulate resize listeners.
• Long-running sessions should continue until the task is complete or report a clear reason for stopping.
• A failed child-process spawn should not permanently break all subsequent shell-tool invocations in that process.
• Empty assistant responses should be retried reliably or surfaced as an explicit error.

Actual Behavior

Actual behavior

There appear to be three observable failure modes:

1. The model returns a normal text message such as "moving to the next check", but no following tool call is made and the turn ends while todo items remain.

2. Some session records contain an assistant entry with an empty content array despite non-zero output-token usage. Command Code sometimes injects Please continue your response..., but recovery is inconsistent.

3. In one traced process, shell spawning later became unusable:

   SHELL [true]
   -> spawn EBADF
   
   SHELL [echo alive]
   -> spawn EBADF
   
   SHELL [echo hello]
   -> spawn EBADF
   

Restarting/resuming may allow the same session to continue for a long time, making the issue appear random.

Steps to reproduce the issue

Reproduction

1. Start or resume a session containing a multi-step coding task with many tool calls.

2. Let it run until it stops while work remains.

3. Resume with warnings and debug output captured:

   NODE_OPTIONS=--trace-warnings commandcode --debug \
     --resume <session-id> 2>&1 | tee /tmp/commandcode-debug.log

4. Continue the task through multiple tool calls.

5. Observe the MaxListenersExceededWarning after the eleventh resize listener is attached.

6. In one reproduced run, continue using shell tools; after several successful commands they begin returning spawn EBADF persistently.

The warning reproduced in two independent resumed processes with different session IDs and exactly the same Command Code bundle location.

Command Code Version

1.53.0

Operating System

macOS

Terminal/IDE

Apple Terminal, TERM=xterm-256color

Shell

No response

Session file (optional)

No response

Fix prompt (optional)

No response

Additional context

The normal --debug log primarily recorded startup/resume information and did not contain the runtime warning. Capturing stderr with NODE_OPTIONS=--trace-warnings was required to obtain the useful stack trace.

commandcode-178c-sanitized.log
commandcode-c89132d7-sanitized.log

[Coding-Dev-Tools]

I investigated this against command-code 1.53.0 (dist/cli.mjs SHA256 b4f5398190f2912d90cecb3c558017f9e0c2c97d55ccf6b66848eed910642859). The MaxListenersExceededWarning for resize is independently reproducible without paid inference.

Root Cause & Bundle Anchors

In dist/cli.mjs, three separate hooks attach listeners directly to stdout:

• useTerminalWidth() at offset 1867924 (14 call sites in bundle):
  e.on("resize", t); return () => e.off("resize", t);
• useTerminalRows() at offset 1868113 (4 call sites):
  e.on("resize", t); return () => e.off("resize", t);
• useTerminalHeight() at offset 1894583 (13 call sites):
  e.on("resize", t); return () => e.off("resize", t);

Why Resume Causes the Warning

In standard interactive turns, components mount incrementally. On session resume (--resume), all historical turn components, message blocks, and status bars in the transcript mount simultaneously during Ink tree hydration (commitHookEffectListMount). Because each component instance using width and height adds two listeners, mounting just 6 components attaches 12 listeners to stdout. As soon as the 11th listener attaches, Node's EventEmitter emits MaxListenersExceededWarning (defaultMaxListeners = 10).

Invariant & Proposed Fix

Similar to the fix in QwenLM/qwen-code#7159:

1. Provide terminal dimensions via a single root React Context (e.g. <TerminalSizeContext.Provider>) at the top of the Ink application tree.
2. The provider subscribes to stdout.on("resize", ...) exactly once (stdout.listenerCount("resize") <= 1).
3. Components consume dimensions via useContext(TerminalSizeContext) rather than attaching directly to stdout.

I verified this invariant in an offline synthetic test: mounting 50 concurrent components via a centralized manager kept stdout.listenerCount("resize") strictly at 1, cleanly dispatched resize events to all 50 subscribers, and returned listener count to 0 upon unmount.

Shell Spawning EBADF

Source analysis of createNodeShell (offset 36586) indicates child processes run with detached: true on macOS ("win32" !== process.platform) with stdio: ["ignore", "pipe", "pipe"] and an exit-grace timeout in onChildFinished (offset 33292). The resize listener leak on stdout does not appear causally linked to spawn EBADF, which is characteristic of parent stdio file descriptor exhaustion in libuv.