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
- 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.
- Run
/tree.
- 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.
Summary
Running
/treeon 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/treeat all — the longer the session, the more certain the crash.Expected Behavior
/treeopens 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:
Steps to reproduce the issue
/tree.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
buildNodeon 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)entryByIdvisitor andbuildToolCallMap's innervisitbuildVisibleNodes,containsId,reorderActiveFirst,flattenVisibleTree's innervisitThese 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:
cmd --session <copy>, captured with tmux, is pixel-identical before and after the change;/treenow 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.