Windows/Codex: MCP tool calls close transport while CLI/stdio init work; update -y still prompts for binary variant

[1234567mm]

Summary

On Windows, codebase-memory-mcp itself appears functional: CLI graph queries work, the current project can be indexed, and a raw stdio MCP initialize request returns a valid response. However, Codex MCP tool calls in the same session fail immediately with Transport closed.

While trying to update/recover the tool, I also hit non-interactive/help-mode issues in codebase-memory-mcp update:

• codebase-memory-mcp update -y still prompts for the binary variant.
• codebase-memory-mcp update --help enters the update flow instead of printing help.
• Piping a variant choice with "1" | codebase-memory-mcp update -y timed out.

Related but not exact duplicates found:

• constant timeouts #474 reports Windows/Codex timeouts, but does not isolate CLI success + raw stdio initialize success + tool-call transport closure.
• Windows stdio MCP handshake hangs — stdout only flushes on stdin EOF (v0.8.1) #513 and Windows: MCP server hangs on initialize when launched by Hermes/AnyIO stdio client #635 cover stdio initialize hangs, but in this case raw stdio initialize succeeds.
• uninstall --help performs a real uninstall — unknown flags silently ignored, no confirmation before destructive removal #1038 covers mutating subcommands ignoring --help; this report adds update -y variant prompting and piped-input timeout.

Environment

• OS: Windows x64
• Shell: PowerShell
• MCP client: Codex Desktop / Codex CLI config
• Codex version metadata: 0.144.5
• Binary: C:\Users\wchao\.local\bin\codebase-memory-mcp.exe
• codebase-memory-mcp version: 0.9.0
• Config entry:

[mcp_servers.codebase-memory-mcp]
command = "C:/Users/wchao/.local/bin/codebase-memory-mcp.exe"

Reproduction and Observed Results

A. Codex MCP tool calls fail, but CLI and raw stdio initialize work

1. In Codex, call a codebase-memory MCP tool such as search_graph, get_architecture, get_graph_schema, or index_repository.

2. Observed Codex-side failure:

tool call failed for `codebase-memory-mcp/search_graph`
Caused by:
    Transport closed

3. Direct CLI calls on the same machine work:

codebase-memory-mcp.exe cli index_repository --repo-path D:\1-QRS\qorder_pr\codex-SpiroSerach --name D-1-QRS-qorder_pr-codex-SpiroSerach --mode fast --persistence false
codebase-memory-mcp.exe cli index_status --project D-1-QRS-qorder_pr-codex-SpiroSerach
codebase-memory-mcp.exe cli search_graph --project D-1-QRS-qorder_pr-codex-SpiroSerach --query NomadPerlaPscProvider --limit 1

Example successful CLI result:

{"project":"D-1-QRS-qorder_pr-codex-SpiroSerach","nodes":8105,"edges":31240,"status":"ready",...}

4. Raw stdio MCP initialize also works. Sending a newline-delimited JSON-RPC initialize request to codebase-memory-mcp.exe returns:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","serverInfo":{"name":"codebase-memory-mcp","version":"0.9.0"},"capabilities":{"tools":{"listChanged":false}}}}

So the failure does not look like a basic missing binary, corrupt index, or stdio initialize failure.

B. Sandbox/write-triggered failure may poison the Codex MCP session

A subagent found that index_repository needs to write under:

C:\Users\wchao\.cache\codebase-memory-mcp

When this write is blocked or fails during the dump phase, Codex reports Transport closed. After that, other Codex MCP tool calls in the same task continue to fail with Transport closed even after the index is rebuilt successfully via CLI. Restarting the individual MCP child processes did not restore the current Codex task's MCP bridge.

C. update -y still prompts

Running:

codebase-memory-mcp update -y

still prompts:

Which binary variant do you want?
  1) standard  - MCP server only
  2) ui        - MCP server + embedded graph visualization
Choose (1/2):

Because there is no stdin in some automation contexts, this fails with:

error: failed to read input

D. update --help enters update flow

Running:

codebase-memory-mcp update --help

entered the update path and prompted/cancelled instead of printing usage and exiting.

E. Piped variant choice timed out

Running:

"1" | codebase-memory-mcp update -y

timed out after ~184 seconds in this environment.

Expected Behavior

MCP transport

• If a tool handler fails due to filesystem permissions or index dump errors, return a JSON-RPC tool error instead of closing stdio.
• After a failed index_repository, subsequent MCP tool calls in the same client session should not remain permanently broken if the server can still initialize and CLI calls work.
• If this is a Codex client incompatibility, it would help to document required Codex config/sandbox permissions or emit a clear diagnostic.

Update CLI

• update -y should be fully non-interactive.
• If a binary variant is required, -y should either preserve the installed variant, choose a documented default, accept an explicit flag such as --standard / --ui, or fail fast with a clear non-interactive error.
• update --help / update -h should print usage and exit without mutation.
• Piped stdin should be consumed or rejected clearly, not hang indefinitely.

Actual Behavior

• Codex MCP tool calls fail with Transport closed.
• Direct CLI queries and raw stdio initialize succeed.
• Rebuilding the current project index via CLI restores CLI graph functionality but does not restore Codex MCP tool calls in the already-running task.
• update -y still prompts for variant.
• update --help enters update flow.
• Piped variant selection timed out.

Workaround

• Use codebase-memory-mcp.exe cli ... directly for query/index operations when Codex MCP bridge is broken.
• Rebuild the current project index via CLI after failed update attempts:

codebase-memory-mcp.exe cli index_repository --repo-path D:\1-QRS\qorder_pr\codex-SpiroSerach --name D-1-QRS-qorder_pr-codex-SpiroSerach --mode fast --persistence false

• Avoid non-interactive codebase-memory-mcp update on Windows for now.
• Restarting/reopening the Codex task may be required to force the Codex MCP client to re-handshake.

Notes

This may be a compatibility issue between recent Codex MCP bridge/session handling and codebase-memory-mcp failure behavior, rather than a pure server startup bug. The key isolation is: CLI works, raw stdio initialize works, but Codex tool calls continue to fail with Transport closed after a failed tool invocation.