CodeGraph MCP hangs in Cursor and falls back to degraded in-process mode

[zhankun]

I am using CodeGraph MCP in Cursor and have encountered two issues.

Environment

• Client: Cursor IDE
• MCP transport: stdio
• Operating system: macOS
• CodeGraph is installed locally
• Codex is also installed on the same machine for comparison

Issue 1: CodeGraph is invoked even when the project is not initialized

When I open a project that has not been initialized with:

codegraph init

and ask a question in Cursor Chat, Cursor gets stuck at:

Running Codegraph Explore in Codegraph

It does not seem to detect that the project does not contain a .codegraph directory.

However, when I use Codex with the same project, Codex detects that .codegraph is missing and does not invoke the CodeGraph tool.

Expected behavior:

• CodeGraph should check whether the current project contains a .codegraph directory.
• If the project has not been initialized, the MCP tool should fail fast with a clear error instead of hanging.

Issue 2: CodeGraph Explore is very slow or hangs even after initialization

After running:

codegraph init

in the project, Cursor still frequently gets stuck at:

Running Codegraph Explore in Codegraph

It may take a very long time before the request continues.

I do not encounter the same behavior when using Codex with the same machine and project.

Cursor MCP logs

The following logs were captured when the problem occurred:

2026-07-03 17:03:49.092 [error] [Shared MCP process] [CodeGraph MCP] File watcher active — graph will auto-sync on changes
undefined
2026-07-03 17:05:57.136 [info] [Shared MCP process] MCP stdio spawn policy decision: sandboxed=false, sandboxReason=controls_disabled, networkControlsEnabled=false, mcpNetworkMode=unset, mcpNetworkAllowlistCount=0, mcpNetworkDenylistCount=0, localAgentNetworkAllowlistCount=0, sandboxPolicyHash=xxxxxxxxxxxxxxxxxxx
2026-07-03 17:05:57.630 [info] [Shared MCP process] Successfully connected to stdio server
2026-07-03 17:05:57.630 [info] [Shared MCP process] [V2 FSM] connection:connect_success: conn=connecting,auth=valid -> conn=connected,auth=valid
2026-07-03 17:07:03.506 [error] [Shared MCP process] [CodeGraph MCP] Shared daemon unavailable; serving this session in-process (degraded).
undefined
2026-07-03 17:18:01.599 [error] [Shared MCP process] [CodeGraph MCP] Parent process exited (ppid 66765 -> 1); shutting down.
undefined
2026-07-03 17:18:01.691 [error] [Shared MCP process] Error calling tool 'codegraph_explore': MCP error -32000: Connection closed MCP error -32000: Connection closed

Observations

The most suspicious log entry is:

Shared daemon unavailable; serving this session in-process (degraded).

After that, the MCP process eventually detects that its parent process has exited and shuts down. The active codegraph_explore request then fails because the connection is closed.

It appears that CodeGraph may be falling back to an in-process degraded mode, and the request either hangs or becomes dependent on the Cursor MCP parent process remaining alive.

Questions

1. Why is the shared daemon unavailable in Cursor?
2. Is the degraded in-process fallback expected to support long-running codegraph_explore requests?
3. Could the fallback mode be causing the long delay or hang?
4. Does CodeGraph rely on a workspace path or project path argument from the MCP client?
5. Does CodeGraph explicitly check for the .codegraph directory before executing codegraph_explore?
6. Why does the same CodeGraph setup work normally in Codex but not in Cursor?
7. Is there any additional debug logging that I can enable to capture the tool arguments, daemon startup failure, and execution duration?

cursor version:
Version: 3.9.16 (Universal)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Expected behavior:

• Return immediately with a clear error when .codegraph is missing.
• Avoid silently entering a degraded mode that causes long-running tool calls to hang.
• Keep the MCP connection alive while codegraph_explore is running.
• Provide a clear diagnostic message when the shared daemon cannot be started.