VS Code extension: GitHub MCP hits 120s timeouts while direct server probes succeed, then degrades to transport closed/stdin destroyed

What version of the IDE extension are you using?

26.304.20706

What subscription do you have?

Not sure this is relevant to the repro. This was observed in the VS Code Codex extension running in a remote WSL2 workspace.

Which IDE are you using?

VS Code Remote / VS Code Server

What platform is your computer?

Linux Markus-Desk-01 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64 GNU/Linux

Ubuntu 24.04.3 LTS (WSL2 remote)

What issue are you seeing?

GitHub MCP calls inside the VS Code Codex extension intermittently fail with the hard 120s deadline, even though the GitHub MCP server itself is healthy and answers immediately when probed directly through the same local wrapper.

The failure pattern looks like this:

• first phase: GitHub MCP tool calls intermittently fail with timed out awaiting tools/call after 120s
• second phase: the same GitHub MCP tool calls start failing with tools/call failed: Transport closed
• third phase: the host/extension degrades into stdin is destroyed and Codex process is not available

This affects normal GitHub MCP read calls, not just one specific tool. I observed it on:

• github/get_me
• github/get_file_contents
• github/list_branches
• github/actions_list

Representative Codex log excerpts:

2026-03-07 05:22:13.227 [warning] [CodexMcpConnection] ... `github/actions_list` ... timed out awaiting tools/call after 120s
2026-03-07 05:24:33.412 [warning] [CodexMcpConnection] ... `github/get_file_contents` ... timed out awaiting tools/call after 120s
2026-03-07 05:26:39.169 [warning] [CodexMcpConnection] ... `github/get_me` ... timed out awaiting tools/call after 120s
2026-03-07 05:28:39.174 [warning] [CodexMcpConnection] ... `github/list_branches` ... timed out awaiting tools/call after 120s
2026-03-07 05:29:01.620 [warning] [CodexMcpConnection] ... `github/get_me` ... tools/call failed: Transport closed
2026-03-07 05:29:37.969 [error] [CodexMcpConnection] Codex process fatal error ...
2026-03-07 05:56:40.258 [warning] [CodexMcpConnection] Attempted to send app-server message but stdin is destroyed ...

The strongest signal is that the direct server path stays healthy while the Codex-hosted path wedges:

{"direct_wrapper_ok":true,"get_me_ok":true,"actions_ok":true}

That direct probe was run against the same local GitHub MCP wrapper and auth on the same machine/session.

What steps can reproduce the bug?

1. Run the VS Code Codex extension in a remote WSL2 workspace.
2. Configure GitHub MCP through a local wrapper that starts ghcr.io/github/github-mcp-server over stdio.
3. Use focused toolsets instead of all:

• --toolsets=default,actions,notifications

1. In the Codex extension, call several GitHub MCP read tools in normal usage:

• github/get_me
• github/get_file_contents
• github/list_branches
• github/actions_list

1. Observe intermittent 120s tool deadline failures.
2. After one or more failures, observe a degraded state:

• Transport closed
• stdin is destroyed
• Codex process is not available

1. In the same environment, probe the GitHub MCP server directly via the wrapper outside the extension. The server still responds immediately.

The running GitHub MCP server at the time of failure was already narrowed to:

github-mcp-server stdio --toolsets=default,actions,notifications

So this does not look like a simple --toolsets=all overload anymore.

What is the expected behavior?

• If the MCP server is healthy, the extension should not hang until the global 120s deadline.
• If transport breaks, the host should reconnect or respawn the MCP server automatically instead of remaining wedged.
• The user-visible error should distinguish between:
• server-side timeout
• host-side deadline timeout
• broken transport / dead stdin
• Stale/broken MCP server processes should be cleaned up deterministically.

Additional information

Environment details:

• GitHub MCP server version observed at startup: v0.32.0
• Node: v22.21.0
• pnpm: 10.30.1
• gh: 2.83.2

This seems related to, but not identical with, these existing issues:

• #3237
• #6127
• #6661
• #7150
• #7281

The closest match is probably #7281 because I also observed stale GitHub MCP server processes earlier in the session, but this report adds a cleaner split:

• direct GitHub MCP server probes succeed
• Codex-hosted MCP path times out and then degrades at the transport/host layer

If helpful, I can provide a tighter minimal repro script for the direct wrapper probe as text.