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

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.

Riproduci il fallimento con una sessione più profonda di circa 2.000 voci, quindi ispeziona i walker indicati nell’issue, iniziando da SessionStoreV3.getTree() e buildNode in dist/cli.mjs. Controlla anche i visitor del navigatore dell’albero e gli helper dei nodi visibili. Il lavoro è completato quando /tree si apre per sessioni profonde senza un RangeError, preservando l’output di attraversamento e il comportamento di navigazione riportati.