UI binary crashes (clean exit) while rendering 3D graph

Bug Report

Description

The ui variant binary crashes with a clean exit (no error message, no stack trace)
while the 3D graph is rendering in the browser. The process simply terminates silently.

Environment

Version: 0.7.0
OS: macOS 26.2 (Build 25C56)
Arch: darwin arm64
RAM: 16 GB
Variant: ui (installed via install.sh --ui)

Steps to Reproduce

Install the UI variant: curl -fsSL .../install.sh | bash -s -- --ui
Run: tail -f /dev/null | codebase-memory-mcp (to keep stdin open)
Open http://localhost:9749
Wait for 3D graph to render

Observed Behavior

Process exits cleanly mid-render. Logs only show:
level=info msg=mem.init budget_mb=8192 total_ram_mb=16384

No crash dump, no error, no signal info.

Expected Behavior

Graph renders without crashing the process.

Additional Notes

The MCP stdio tools (search_graph, trace_path, etc.) work fine
Crash is reproducible every time the graph attempts to render
KeepAlive in LaunchAgent does not restart the process after this crash

Thanks for the report. A clean exit (no signal, no stack) mid-render points to a deliberate exit path rather than a SIGSEGV — the UI server runs alongside the MCP stdio loop, so the whole process goes down if either side exits. I can't reproduce it without a bit more:

Exit code — capture it right after it dies (e.g. …; echo "exit=$?").
Verbose stderr up to the exit — paste the last ~30 lines (the only line so far is mem.init).
Graph size — the nodes/edges from the index_repository response for the project you're viewing (you're on 16 GB / budget 8192 MB, so I want to rule out a size/budget exit).
Does it reproduce with a small project (a few files), or only on a large graph?
After the exit, do the MCP stdio tools still respond, or is the whole process gone?

A repro project (or just its approximate node/edge count) would help most.

One material change since my last comment: v0.8.1 replaced the UI's entire HTTP transport layer with a new implementation. Worth retesting the 3D graph view there — could you give v0.8.1 a try?

If it still exits cleanly mid-render, the details from above (terminal output at exit, the tail of the --ui log) would localize whether it's the render path or the server side going down.

Also seeing this issue appear. I have an extremely large codebase that's multilingual (GO, Dart, TypeScript, etc.). The knowledge graph contains 50,634 nodes and 261,567 edges. The UI, when I try to load the graph, crashes the whole utility.

alden@Mac ~ % codebase-memory-mcp --ui=true --port=9749
level=info msg=mem.init budget_mb=18432 total_ram_mb=36864
zsh: killed     codebase-memory-mcp --ui=true --port=9749

One material change since my last comment: v0.8.1 replaced the UI's entire HTTP transport layer with a new implementation. Worth retesting the 3D graph view there — could you give v0.8.1 a try?

If it still exits cleanly mid-render, the details from above (terminal output at exit, the tail of the --ui log) would localize whether it's the render path or the server side going down.

v0.8.1 is not working too
macbook pro m1pro's chrome

I also came across the problem，and the output in terminal was:

codebase-memory-mcp --ui=true --port=9749
level=info msg=mem.init budget_mb=18432 total_ram_mb=36864
zsh: killed codebase-memory-mcp --ui=true --port=9749

my codebase has 76008 nodes and 271597 edges, the version of codebase-memory-mcp is 0.8.1

Thanks to everyone who chimed in — the pattern is clear: --ui=true on graphs above
roughly 50 k nodes reliably hits killed on macOS Apple Silicon. We're working on a
fix and need to distinguish OOM (SIGKILL from the OS) from an internal assert.

Instructions for your coding agent:

# 1. Capture the exit signal precisely
codebase-memory-mcp --ui=true --port=9749 &
CBM_PID=$!
# Open the UI in the browser, wait for it to die, then:
wait $CBM_PID
STATUS=$?
echo "exit_status=$STATUS"

# 2. While it's running, sample RSS until it dies (run in a second terminal)
while pgrep -x codebase-memory-mcp > /dev/null; do
  ps -o pid,rss,vsz -p "$(pgrep codebase-memory-mcp)" 2>/dev/null
  sleep 2
done
echo "process gone"

# 3. Check for a macOS crash report (written even for OOM kills)
ls -lt ~/Library/Logs/DiagnosticReports/ 2>/dev/null | \
  grep -i codebase | head -5
# If any exist, paste the first 50 lines of the most recent .ips file

# 4. Confirm graph size
codebase-memory-mcp cli list_projects 2>/dev/null | grep -E 'nodes|edges'

# 5. System info
sw_vers
sysctl -n hw.memsize | awk '{printf "%.0f GB\n", $1/1073741824}'

The macOS crash report (.ips in ~/Library/Logs/DiagnosticReports/) is the most
valuable artifact — it contains the termination reason and, for OOM kills, the memory
footprint at kill time.

Thank you for your patience while we get this fixed!

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

the codebase-memory-mcp --version you're on
the exact steps or command you ran
a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

fix(ui): bound octree recursion for coincident points (3D layout)

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will be closed in 14 days if there's no update — just add a comment to keep it open. We're happy to pick it back up the moment we can reproduce it.

Thanks again to everyone who supplied graph sizes and kill output here.

Current main now limits the default graph UI fetch and server layout budget to 5,000 nodes, with server-side clamping and regression coverage. The old 50,000-node default used by the reported v0.7.0 and v0.8.1 cases is no longer used.

Could someone who reproduced this please retest using the default node budget on the latest version available to you? If the process is still killed, please share the exact exit status and peak RSS if available. Please do not share proprietary source code.

I am keeping this open and awaiting reporter confirmation rather than closing it based only on the current-main code change.

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.

Thank you all for the graph sizes and kill output; they pointed straight at the cause! The UI used to lay out up to 50,000 nodes by default, and on these graphs that was enough for macOS to kill the process. Since v0.9.0, the default fetch and server-side layout are capped at 5,000 nodes, with server-side clamping. The graph UI is also being replaced by a new frontend. Could someone who hit this try the default view on v0.11.0? If it's still killed, the exit status and the peak RSS would help. If nobody reports back, we'll close this as fixed.

fix(csharp): refresh grammar for collection expressions in conditiona…

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.

Thank you for the graph-size and process-exit evidence. If you have already retested the default view on a newer release, please share its version and outcome. Please do not force another large render that risks killing the process; the existing evidence remains available for maintainer follow-up.

Navigation Menu

Repository navigation

UI binary crashes (clean exit) while rendering 3D graph #402

Bug Report

Description

Environment

Steps to Reproduce

Observed Behavior

Expected Behavior

Additional Notes

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

UI binary crashes (clean exit) while rendering 3D graph #402

Description

Bug Report

Description

Environment

Steps to Reproduce

Observed Behavior

Expected Behavior

Additional Notes

Activity

DeusData commented on Jun 6, 2026

DeusData commented on Jun 12, 2026

kNoAPP commented on Jun 17, 2026

xiaokyo commented on Jun 23, 2026

tanglinhong commented on Jun 23, 2026

DeusData commented on Jun 26, 2026

github-actions commented on Jun 26, 2026

github-actions commented on Jul 30, 2026

DeusData commented on Aug 21, 2026

github-actions commented on Sep 13, 2026

DeusData commented on Sep 25, 2026

github-actions commented on Oct 18, 2026

DeusData commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions