UI /api/layout drops connection for large graph when max_nodes is high

[sharif-smj]

Summary

The graph UI fails for a large indexed private repository. Indexing succeeds and CLI/MCP graph queries work, but opening the project in the browser UI causes /api/layout to hang and then drop the connection without a JSON error response.

This appears isolated to the browser UI layout endpoint, not the core indexer.

Environment

• codebase-memory-mcp --version: 0.8.1
• Binary: UI release asset for macOS arm64
• OS: macOS arm64
• UI URL: http://127.0.0.1:9749

Project size

The indexed private project is roughly:

• 23k nodes
• 96k edges

list_projects and get_architecture work for this project.

Reproduction

After indexing a large project, open it in the graph UI, or call the layout endpoint directly:

curl -v 'http://127.0.0.1:9749/api/layout?project=<large-private-project>&max_nodes=50000'

Observed result:

curl: (52) Empty reply from server

In Chrome, the graph page shows:

Failed to fetch

The request hangs for roughly 20-35 seconds before the connection is dropped. The local UI process then restarts if supervised externally.

Threshold observed locally

These returned successfully:

max_nodes=10000
max_nodes=12000
max_nodes=14000

These failed or caused the UI server connection to be dropped:

max_nodes=16000
max_nodes=20000
max_nodes=50000

The bundled frontend appears to request max_nodes=50000 when loading a graph.

Expected behavior

For large projects, the UI should ideally do one of the following:

• render a bounded layout that the server can handle,
• automatically lower max_nodes,
• stream/progressively load layout data,
• or return a structured JSON error instead of dropping the connection.

Notes

I intentionally redacted the repository name, local paths, and project-specific identifiers because this was reproduced against a private codebase. Happy to provide more diagnostics if there is a safe way to collect them without exposing source or project details.

[DeusData]

Thanks for the careful report and for keeping the private repo details out. This is a valid UI/server resilience bug: the layout endpoint needs a bounded default and a structured failure path instead of letting a large graph drop the connection. I’m tracking it under the large-repo performance epic and marking it high priority for the graph UI path. The thresholds you included are already actionable.

[rudi193-cmd]

Data point — willow-2.0 graph size (v0.8.1, linux-amd64)

Public repo: willow-2.0. Indexed project home-sean-campbell-github-willow-2.0:

Metric	Value
Nodes	17,835
Edges	57,740
Status	ready

This is a Python-heavy fleet monorepo (hooks, MCP server, Kart worker, Postgres bridge) — relevant to your question about edge density after the 10k max_nodes cap on current main.

We have not exercised the UI layout endpoint directly; we use CBM via stdio/cbm_* MCP tools for audits. Flagging the numbers in case they help scope the adjacency-list fix: at full index size we sit just above the 10k cap, so any UI path that clamps to 10k nodes still sees a substantial edge set and would hit compute_call_depth on a filtered subgraph.

Audit context (graph = discovery, not measurement): docs/audits/CODEBASE_MEMORY_MCP_TOOL_EVAL_ADDENDUM_2026-07-05.md

[github-actions]

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.

[DeusData]

v0.9.0 includes graph layout/rendering stability work for much larger graphs, so this dropped layout request needs a current retest. Could you try v0.9.0 and report whether /api/layout still disconnects on the same repo? Marking awaiting-reporter.