/tree crashes with RangeError: Maximum call stack size exceeded on sessions deeper than ~2k entries

Reproduce el fallo con una sesión de más de aproximadamente 2.000 entradas y, después, inspecciona los walkers mencionados en el issue, empezando por SessionStoreV3.getTree() y buildNode en dist/cli.mjs. Comprueba también los visitantes del navegador del árbol y los helpers de nodos visibles. La tarea estará terminada cuando /tree se abra para sesiones profundas sin un RangeError, conservando la salida de recorrido y el comportamiento de navegación indicados.

Summary

Running /tree on a session with a long history crashes the CLI. The tree never opens: the TUI prints an unhandled promise rejection (RangeError: Maximum call stack size exceeded) and the process exits back to the shell. Long-running sessions therefore cannot use /tree at all — the longer the session, the more certain the crash.

Expected Behavior

/tree opens the session-tree navigator for any session, regardless of how many entries it has.

Actual Behavior

The navigator never renders; the CLI prints the standard crash block and exits:

✖ CRITICAL: Unhandled Promise Rejection!
This is an unexpected error. Please file a bug report at https://github.com/CommandCodeAI/command-code/issues/new
✖ ERROR → RangeError
ℹ REASON → Maximum call stack size exceeded
ℹ ERROR STACK ↓
 RangeError: Maximum call stack size exceeded
    at buildNode (file:///…/command-code/dist/cli.mjs:2:537086)
    at Array.map (<anonymous>)
    at buildNode (file:///…/command-code/dist/cli.mjs:2:537120)
    at Array.map (<anonymous>)
    at buildNode (file:///…/command-code/dist/cli.mjs:2:537120)
    ...

Steps to reproduce the issue

1. Use a session whose tree is deeper than roughly 2–3k entries — a long linear conversation (depth == number of entries) is enough; heavy rewinding/forking also builds depth.
2. Run /tree.
3. The CLI crashes instead of opening the navigator.

Observed with a 12 MB transcript: 4,275 entries, tree depth 4,266, 3 roots, no cycles and nothing corrupt. For contrast, an empty session correctly shows "No session entries yet." without crashing, and a 700-entry session (depth 687) opens fine.

Isolated measurements of the shipped buildNode on synthetic linear chains: depth 2,000 → OK, depth 3,000 → RangeError.

Command Code Version

1.54.1 (latest on npm at the time of writing, so there is no newer release to upgrade to)

Operating System

Linux

Terminal/IDE

tmux 3.x

Shell

fish

Session file (optional)

Not attached — the repro transcript is 12 MB. Happy to share it privately, or run anything you'd like against it.

Fix prompt (optional)

The session-tree walkers recurse once per tree level, so stack depth is proportional to session depth. Convert them to explicit-stack iteration:

• SessionStoreV3.getTree() → buildNode (cli.mjs ≈ 2:537086): const r=(e.get(n.id)??[]).slice().sort(t).map(buildNode)
• the tree navigator's entryById visitor and buildToolCallMap's inner visit
• buildVisibleNodes, containsId, reorderActiveFirst, flattenVisibleTree's inner visit

These are all pure traversals with no depth-dependent behavior, so the output should be identical.

Additional context

I patched all seven walkers locally to explicit-stack iteration and verified:

• the walkers return byte-identical output (JSON, key order included) versus the recursive originals across linear / branchy / wide (13.5k nodes) / deep trees;
• rendering a 700-entry and a 338-entry session via cmd --session <copy>, captured with tmux, is pixel-identical before and after the change;
• /tree now opens and navigates the 4,266-deep session (filters, fold/unfold, Esc all work), plus a synthetic 30k-deep one, with no crash.

That patch is a local edit to the minified dist/cli.mjs (it is overwritten on upgrade), so it is not a fix to ship — but the approach may save someone time. I can send the patch script if useful.

Note: the investigation, reproduction and patch above were produced by an AI coding agent (Command Code itself) working against the shipped bundle.