MCP client for `codegraph` failed to start: MCP startup failed: handshaking with MCP server failed: connection closed: initialize response

[roldzai]

Summary

The codegraph MCP server is enabled and the LazyCodex session-start bootstrap reports success, but Codex cannot complete MCP startup because the server process closes before returning an initialize response.

Environment

• LazyCodex / OMO plugin: omo@sisyphuslabs 4.12.0
• Codex CLI: codex-cli 0.141.0
• CodeGraph: 1.0.1
• Node: v24.16.0
• OS: CachyOS rolling, Linux 7.0.12-1-cachyos, x86_64
• Install/config source: local plugin cache at /home/ngct/.codex/plugins/cache/sisyphuslabs/omo/4.12.0
• Relevant config:

[plugins."omo@sisyphuslabs".mcp_servers.codegraph]
enabled = true

Repository Decision

• Target repository: code-yeongyu/lazycodex
• Why this belongs there: LazyCodex/OMO owns the bundled codegraph MCP registration, startup hook, and wrapper that Codex launches. Upstream Codex is reporting the generic MCP startup error after the server closes during handshake.
• LazyCodex evidence: latest synced source at /tmp/lazycodex-source commit b9d9a9e; wrapper source is plugins/omo/components/codegraph/src/serve.ts, which resolves CodeGraph and runs codegraph serve --mcp with inherited stdio.
• Upstream Codex evidence: latest synced source at /tmp/openai-codex-source commit d667082; codex-rs/codex-mcp/src/connection_manager.rs formats the observed MCP client for ... failed to start message from a startup error, while codex-rs/codex-mcp/src/rmcp_client.rs wraps the lower-level MCP startup failure.

Reproduction

1. Start Codex with the OMO plugin codegraph MCP server enabled.
2. Observe the session-start hook schedule CodeGraph bootstrap.
3. Codex reports:

MCP client for `codegraph` failed to start: MCP startup failed: handshaking with MCP server failed: connection closed: initialize response

I also reproduced the failing stdio behavior directly, outside Codex, by starting the provisioned CodeGraph MCP server and sending a JSON-RPC initialize request:

/home/ngct/.omo/codegraph/bin/codegraph serve --mcp --path /home/ngct/Projects/tmp

With direct mode forced:

CODEGRAPH_NO_DAEMON=1 /home/ngct/.omo/codegraph/bin/codegraph serve --mcp --path /home/ngct/Projects/tmp

Both paths exited before returning an initialize response.

Expected Behavior

codegraph serve --mcp should keep the stdio transport alive and return a JSON-RPC initialize response so Codex can finish MCP startup and list CodeGraph tools.

Actual Behavior

The server process exits cleanly before responding.

Direct repro result:

{"elapsedMs":96,"code":0,"signal":null,"stdout":"","stderr":""}

The same no-stdout/no-stderr shape occurs through the OMO wrapper:

node /home/ngct/.codex/plugins/cache/sisyphuslabs/omo/4.12.0/components/codegraph/dist/serve.js

Evidence

Session-start bootstrap succeeded before the MCP handshake failed:

{"exitCode":0,"projectRoot":"/home/ngct/Projects/tmp","source":"provisioned","timedOut":false,"action":"initialized","timestamp":"2026-06-20T04:44:03.906Z"}

The workspace is initialized: /home/ngct/Projects/tmp/.codegraph points to /home/ngct/.omo/codegraph/projects/tmp-e2ff39b3cfa72e63, and that target contains codegraph.db.

The installed CodeGraph bundle indicates serve --mcp should be the stdio MCP entrypoint and should answer initialize before heavy initialization. The installed session implementation sends the initialize result before calling engine.ensureInitialized(...).

Root Cause

Confirmed symptom: the provisioned CodeGraph 1.0.1 MCP server exits with status 0 and no output before sending a JSON-RPC initialize response. This causes Codex's MCP client to report connection closed: initialize response.

Likely LazyCodex diagnostic gap: the OMO wrapper currently propagates only the child process exit code. A quick clean exit with no handshake response gives Codex a closed connection without an actionable CodeGraph-specific error.

What remains uncertain: why the installed CodeGraph server exits before its documented/session-code initialize path runs on this machine. The repro rules out an uninitialized workspace and a simple daemon/proxy-only path because direct mode also exits silently.

Proposed Fix

Add an end-to-end stdio handshake smoke test around the real/provisioned codegraph serve --mcp path, not only wrapper invocation with a fake binary.

Likely implementation areas:

• plugins/omo/components/codegraph/src/serve.ts: detect quick clean exit before handshake and print an actionable stderr diagnostic.
• CodeGraph serve --mcp startup path: ensure the process remains alive long enough to read stdin and answer initialize, including when launched by Codex/OMO with inherited stdio.

Verification Plan

• Run codegraph serve --mcp --path <initialized-project>.
• Send a JSON-RPC initialize request over stdin.
• Confirm stdout contains an MCP initialize response.
• Confirm Codex no longer reports connection closed: initialize response.
• Regression-check disabled and missing-binary paths still emit the existing one-line skip hints.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated