Windows: MCP tools hang after index reports ready

[tiendungdev]

Describe the bug

On Windows, Gortex MCP tools can stop returning responses even though the MCP connection advertises the repository index as ready (phase: enrichment_complete). The client has to terminate each tool call manually; no timeout or actionable error is returned.

This was observed in a Codex MCP stdio session. Normal PowerShell, Git, and Gortex CLI version commands remained responsive while the MCP calls were stuck.

To reproduce

1. Start a Codex session with Gortex MCP enabled for an indexed repository on Windows.

2. Confirm the Gortex MCP tool metadata reports:

   • one tracked repository
   • an active project
   • index status ready / enrichment_complete

3. Invoke the following minimal tool call:

   {
     "tool": "index_health",
     "arguments": {
       "compact": true,
       "format": "gcx",
       "max_bytes": 6000
     }
   }

4. Wait for a response.

Observed in the latest probe: no output after 30 seconds; the client terminated the call.

A separate individual smart_context call also produced no output for more than 60 seconds and had to be terminated. Follow-up grouped probes involving read_file, index_health, and tool_profile likewise failed to complete.

Expected behavior

The MCP tool should return its result, or fail with a bounded timeout and an actionable error. A repository advertised as ready should not leave read-only health/context calls pending indefinitely.

Actual behavior

The request remains pending without output until the MCP client cancels it.

Environment

• OS: Windows Pro 25H2, build 26200.8737
  • The Windows registry's legacy ProductName value reports Windows 10 Pro.
• Architecture: windows/amd64
• Gortex: v0.60.0+dd3bb30
• Gortex commit: dd3bb30
• Gortex build date: 2026-07-09T19:37:24Z
• Go used to build Gortex: go1.26.4
• Local Go CLI: go1.25.10 windows/amd64
• Client/transport: Codex, MCP stdio

Daemon / standalone context

gortex status reports that no daemon is running. According to gortex mcp --help, the embedded server should be used automatically when no daemon is available.

One earlier gortex daemon status attempt reported that access to the cached daemon socket was forbidden; later status calls reported no running daemon. This may be a separate stale-socket/environment symptom and is not claimed as the root cause of the MCP hang.

Impact

• Each affected MCP call blocks the agent for 30–60+ seconds.
• The call must be cancelled manually.
• Work has to fall back to filesystem/CLI tools.
• There is no error that tells the user whether the index, embedded MCP server, daemon discovery, or Windows IPC is responsible.

Workaround

Terminate the pending MCP call and use direct filesystem/CLI tooling. A clean MCP/daemon restart has not yet been isolated as a reliable workaround.

Duplicate check

Searched open and closed issues for Windows MCP hangs, standalone MCP hangs, smart_context timeouts, and daemon socket access errors. No matching issue was found. Issue #113 concerns a different daemon warm-path/indexing hang.

Additional context

• The minimal index_health probe was repeated immediately before filing and was cancelled after 30 seconds with no output.
• Telemetry is disabled.
• No repository source, local username, credentials, tokens, or private paths are included in this report.

[tiendungdev]

I traced the current main paths after filing this from v0.60.0. There appears to be a request-lifetime parity gap worth testing independently of the still-unproven underlying lock/block cause:

• daemon socket sessions now pass through internal/daemon/mcp_request_lifetime.go (d8a8bca1, DefaultMCPToolCallTimeout = 60s) and can return a terminal JSON-RPC deadline response
• the automatic embedded fallback in cmd/gortex/mcp.go still calls srv.ServeStdio() directly; internal/mcp.Server.ServeStdio delegates to mcp-go's stdio worker pool, which has no per-request deadline in the pinned v0.56.0 transport
• handleIndexHealth receives a context, but buildIndexHealthPayload does not accept/check it while collecting graph stats, stale files, file nodes, and per-repo file metadata. That makes it a plausible uncooperative handler if a graph/store operation blocks, but I do not yet have a stack/profile proving that it is the root cause.

Proposed acceptance contract for a separate fix:

1. an embedded-stdio regression test installs a deliberately blocking tool handler
2. the request receives a terminal deadline response within a short test timeout
3. a subsequent request on the same stdio session still completes
4. daemon and embedded paths expose equivalent cancellation/deadline semantics without unbounded detached work

The clean implementation may be a transport-neutral extraction of the existing daemon request-lifetime machinery, but PR #273 is already changing MCP session/connection behavior. Alternatively, the timeout could be added to the upstream mcp-go stdio transport and consumed here. I would prefer maintainer direction on that boundary before sending code.

I would keep index_health context/scan optimization out of the first liveness PR until a Windows trace identifies the blocking phase.