/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.

Reproduziere den Fehler mit einer Sitzung, die deutlich mehr als ungefähr 2.000 Einträge enthält, und untersuche anschließend die im Issue genannten Walker, beginnend mit SessionStoreV3.getTree() und buildNode in dist/cli.mjs. Überprüfe ebenfalls die Besucher des Tree-Navigators und die Helper für sichtbare Knoten. Als erledigt gilt die Aufgabe, wenn /tree für tiefe Sitzungen ohne einen RangeError geöffnet wird und dabei die gemeldete Traversierungsausgabe sowie das Navigationsverhalten erhalten bleiben.