issue_write update (state: closed) hangs — mutation succeeds but no response is ever returned

[edimuj]

Summary

issue_write with method: "update" and state: "closed" performs the GitHub mutation but never returns a JSON-RPC response. The issue is successfully closed (confirmed in the GitHub UI), but the MCP tool call hangs and the client must time out or be interrupted. Other issue_write update calls (e.g. editing the body or labels without a state change) return normally within a second or two.

Environment

• github-mcp-server: 1.0.3 (commit 4bded57e02e9346cb1fd595156e07dea51f0fb29)
• Transport: stdio (github-mcp-server stdio)
• Auth: PAT via GITHUB_PERSONAL_ACCESS_TOKEN
• OS: Linux (Ubuntu, Node 24 MCP client)
• The server is reached through a proxy (callmux), but the symptom is at the JSON-RPC layer: the request is dispatched, the GitHub mutation lands, and no tools/call response message is ever sent back. The proxy only observes a pending call with no reply.

Reproduction

Call issue_write with a state transition to closed plus labels:

{
  "method": "update",
  "owner": "<owner>",
  "repo": "<repo>",
  "issue_number": 158,
  "state": "closed",
  "state_reason": "completed",
  "labels": ["infra", "fixed"]
}

Expected

The tool returns the updated issue (URL / number / state) within a couple of seconds, the same as any other issue_write update.

Actual

• The issue is closed on GitHub (the underlying API mutation succeeds).
• No response is returned to the MCP client — the tools/call never completes.
• The client hangs until it hits its own call timeout (or is manually interrupted).

Impact

Because the call never returns, an agent driving the server has no way to know the operation succeeded. It either blocks for the full client-side timeout window or interrupts and may incorrectly treat the close as failed (and, worse, retry it). A consistently-returned response — even just the updated issue object — would resolve this.

Notes / guesses

The hang appears specific to the state-change-to-closed path (a plain label/body update on an open issue returns fine). It looks like the update handler may complete the mutation but block or fail to write the response when state: "closed" (possibly combined with state_reason / labels) is part of the same call. Happy to capture stderr / a protocol trace if that would help narrow it down.