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

Aberta
#835 5 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Precisa de esclarecimento
Status de atividade
Ativa
Stack de tecnologia
node.js, react

Direção de pesquisa

Comece reproduzindo o aviso com NODE_OPTIONS=--trace-warnings e --debug --resume; em seguida, inspecione a localização agrupada em dist/cli.mjs e os stack frames relacionados de Ink/React. Compare os dois logs sanitizados anexados e rastreie separadamente as falhas de resize-listener e shell-spawn. Considera-se concluído quando as sessões retomadas não acumularem mais resize-listener e as falhas de shell-spawn relatadas forem compreendidas e tratadas.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

  • CommandCodeAI/command-code#601 — long sessions periodically stop with pending work and no error.
  • 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.
  • CommandCodeAI/command-code#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

Linguagem predominante
Sem dados de linguagem
Estrelas
4k
Forks
350
Métricas de merge de PRs
Nenhum PR com merge em 30d

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de CommandCodeAI/command-code

Todas as issues de CommandCodeAI/command-code

Issues semelhantes

Mais issues de CLI

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.